[Bf-committers] Menu code bug/weirdness

bf-committers@blender.org bf-committers@blender.org
Sat, 21 Feb 2004 06:36:42 -0600

Ton Roosendaal wrote:
> For very long listings, such all bones in an armature, the Blender  
> pulldowns don't work well. We could adopt the OSX convention, where you  
> can scroll inside of a pulldown, with an arrow icon in top and/or  
> bottom to indicate you can scroll. That way the usage of a 'DataBrowse'  
> can become optional (or obsolete) too.

I don't think the scrolling would work very efficiently from a
work flow perspective.  I understand it might be desireable to
allow this to happen should the menu grow too big for the screen,
which is possible.  However, I already find the current situation
where I have to open up a menu to flip between vertex groups,
especially when in weight paint mode to be cumbersome.  I've
felt it would be very nice to allow some key strokes to switch
selected vertex groups and other items without popping open the

I have no idea how this would work from a user perspective though.
You'd either have to have a special set of hot keys bound to this,
possibly mode dependent, or force the user to hover the cursor
over the menu button.

The rest of the issues you brought up sound fine to me.  It is
confusing to have the order switch, but if you're normally
using the menus from about the same position on the screen, you
generally get the same menu.  Having sorted vertex group menus
vs the old non-ordered ones was a big boost to me, even with
the menus occasionally flipping because I forced a panel to
full screen or accessed the menu from a different spot on the
screen than I normally do.

One of the reasons I wanted to implement this as a flag to menu
creation, i.e. SORTED_MENU or something like that, was it would
be nice to see images, materials, textures, etc. sorted as well
as the vertex groups and now bones.  It didn't make any sense to
me to put sorting code in all those places.

Getting rid of the DataBrowse would be desireable also.  If you can
make the OSX type scrolling menus work fast from a work flow
perspective and it dealt with both of these issues, that'd be
great.  I just can't see how popping the menu up, then scrolling
it somehow could be as efficient of work flow as popping the
menu up and then clicking the item you want.

Todd Koeckeritz, zaz@visi.com

Surfin' the Web with an ActiveX enabled browser is kindof like having
to worry about getting shot everytime you knock on a door.