[Bf-committers] GUI menu locked in window
Mon, 26 Apr 2004 17:56:38 -0400
All of which sounds great! And should be added.
My goal is to create an interface that will keep a lot of runaways to
stay a little bit longer. As out lined by this post that eventually
went in to a crap fight, but the begging of it seemed to have some good
outlines of what outsiders think. ANd what still keeps them away.
The different window panes and divisions are a great tool for stream
lining the interface and then using the short cut to hide all other
windows and just work in one full screen window is a great asset to
have as it stands. My idea is just to get the buttons that are just
needed for a constant tack or group of tasks into plain view grouped
together and to disperse with the other buttons that are not needed.
I will work on mock ups.
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 . 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
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
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
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:
> 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.