[Bf-committers] Pupmenu conventions. (Was: CVScommit:blender/source/blender/src edit.c)

Robert Wenzlaff bf-committers@blender.org
Mon, 6 Oct 2003 14:16:11 -0400

On Monday 06 October 2003 11:00 am, Ton Roosendaal wrote:
> The numerical hotkey option for menus is hardcoded in the menu system  
> itself, it always works, and always counts from the top.

Yes.  And code can never be changed, right?

> This is so incredible simple & functional, that I'm really surprised  
> someone thinks to drop that consistancy.

A hammer is also simple, consistant, and functional.  But that doesn't mean 
you can build a house with only a hammer, esp. when everything has been 
changing to screws for years.

> The return event code for 'knife tool' (11) has nothing to do with it.

See.  Even after reading the code, the system is not self explanitory :)

If WKEY is the worst case, then it's exactly what we need to build a tool to 
handle because as functionallity expands, cases aren't going to magicly just 
get better.

The only downside I see, it that the two systems don't work together, meaning, 
if you add a hot char to a new menu item, you have to add a hot char (which 
can be it's old number) to all items in _that_ menu.  But 1) this is only 
typing a few chars in the string, and 2) it can default to the old bevavior 
if there are none given.  

In summary:

Simple && Consistant ==  good  

Hidden* || non-expandable** == bad


good && bad == bad.

My proposal is still consistant (highlighted char ALWAYS triggers item - often 
used combos ARE preserved because they become the highlighted char), and in 
most cases just as simple,  simpler if you are looking for a function by 
grouping - ie; all subdivide methods can be grouped together, even if someone 
comes up with a new one later. 

Unlike the old system this is logically expandable, and self explanitory. 
Counting is not.  If there are over 4 items in the menu, counting is too 
tedious to expect the user to actually do (esp. if there is no indication 
that's how it works).  At that point, they will break their workflow and use 
the mouse.  If we want to stay "the fast-efficient" 3D app, we should strive 
to avoid making them do that.  That's why the number shortcuts are there. 
It's just were starting to outgrow that system.  Do we upgrade it now, or 
stretch it until it breaks?

* a new user has _0_ indication that numeric entry is even allowed in a menu.

** At best, poorly expandable. You can only tack new functions on to the end 
w/o breaking key combos. 
Robert Wenzlaff                 rwenzlaff@soylent-green.com