Re: GUI menu locked in window

One thing I think would be nice is having a stack of
user defined functions in the 3D view. With an easy
way to assign functions to the stack from the header
menu, simple icons, this in itself could be a good way
to make the workflow faster. Especially if it is user
configurable (and as usual saves itself in the .blend
files so you can have per-project setups) and comes
with a good default setup.

Martin

--- trip <trip@xxxxxxxxxx> wrote:
> 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.
> http://www.cgtalk.com/showthread.php? 
> s=&threadid=139661&perpage=15&pagenumber=1
> 
> 
> 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  
> 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



        
                
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash