[Bf-committers] GUI menu locked in window
Ton Roosendaal
bf-committers@blender.org
Tue, 27 Apr 2004 11:40:13 +0200
Hi,
> My current question is. Where is the code that locks a window into a
> window pane? The transform pane is the same window type as the IPO N
> key. So they should be able to move around into each others window
> pane for example, instead of being locked in their own window
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.
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.
(BTW: I don't read cgtalk. If that article has interesting viewpoints,
give us a summary!)
-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@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------
--
Ton Roosendaal Blender Foundation ton@blender.org
http://www.blender.org