Re: GUI menu locked in window

Hello...
> Sorry, but that idea is simply opposite to how it's implemented.  
> Blender has a builtin window manager, that restricts all  
> drawing/events to the window itself. Each subwindow in blender is  
> meant to be totally stand-alone, and should be treated that way.
>
> The only exception case are hotkey menus (like Q key), which are  
> allowed to draw over the entire GUI.

That will be a HUGE stepping stone then...

> And an other important aspect not to forget: we defined strict usage  
> and awareness of "Context" when we re-evaluated the interface last  
> year. You can still read that in the original design doc on our site.  
> This is simply to notice for the Nkey menu for IpoWindow; that one has  
> no use at all to be moved around, would even be extremely confusing  
> when you have 2 ipowindows open for example.

Yes but there is always room for improvement.
> (BTW: I don't read cgtalk. If that article has interesting viewpoints,  
> give us a summary!)

Will do !
^v^


> -Ton-
>
>
> > . While that is a silly idea, it just apart of this idea. The real  
> > meat of the idea is to have ALL menu groups to be able to freely  hop  
> > into each others windows.
> >
> > The next idea is the hard one. To be able to have a new GUI window  
> > pane that will let you create and assign a button to a to your custom  
> > button. So a truly custom menu could be created for supreme speed  
> > work flow. The buttons would just be stock buttons or a simple draw  
> > button thing.
> >
> > Another idea is taken from an out side source. To be able to just  
> > physically drag a button out and onto a menu group. This would not  
> > let you determine the size of the button but it would give the power  
> > of custom.
> >
> > The one and exact reason for all of this is to attract more coders  
> > into the coder base. I am trying to find an answer to the massive  
> > amount of feature requests that are made and dreamed upon but never  
> > created.
> >
> > My other project of Bounty is in the works still. And it is another  
> > idea that complements this.
> >
> >
> >
> >
> > On Apr 25, 2004, at 6:13 AM, Ton Roosendaal wrote:
> >
> > > Hi,
> > >
> > > I find it hard to digest information from this proposal... but it  
> > > resembles one of the design proposals from the original 2.3 todo  
> > > doc.
> > > When I can find time, I wanted to allow to have another (or  
> > > multiple) Blender windows open next to each to each other. This in  
> > > first instance to support dual screen better, but it could also  
> > > allow to visualize multiple Blender scenes on one desktop, multiple  
> > > editmodes, or the rendered window on other screen, etc.
> > > In theory, you then can also "unglue" an existing (subdivision)  
> > > window in Blender to become a real desktop based window. Optional of  
> > > course. I still consider a subdivision system offering better  
> > > workflow than having your desktop cluttered with lotsa overlapping  
> > > windows.
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers@xxxxxxxxxxx
> > http://www.blender.org/mailman/listinfo/bf-committers
> ----------------------------------------------------------------------- 
> ---
> Ton Roosendaal  Blender Foundation ton@xxxxxxxxxxx  
> http://www.blender.org
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@xxxxxxxxxxx
> http://www.blender.org/mailman/listinfo/bf-committers