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

Robert Wenzlaff bf-committers@blender.org
Thu, 9 Oct 2003 10:10:32 -0400

On Thursday 09 October 2003 07:30 am, Ton Roosendaal wrote:
> Hi Robert,
> If you like proposals to be accepted, it's important to read carefully
> what people write, digest that information, and propose something that
> fits better. Giving opinions confuses... and makes the threads hard to
> read.
> I don't have much time for mail these days, so I also made the error of
> too quickly scanning mails, probably irritating you as well. :)

I'm sorry if  I seem irritated, but I think we're going around in circles 
because you are missing the cruicial point of the proposal.  

> Important is to realize that 'hotchars' then are *not* allowed to be a
> number. The new 'hotchar' is added functionality, and doesn't have to
> mess with old conventions at all. SHIFT+S-4 will remain the 4th item.

No.  The problem is the 4th item might change and then the behavior of 
memorized combo like SHIFT-S-4 changes.  Look what happened to the "W" menu 
when I put "Knife" in with the other subdivides.  "W-4" changed from "Merge" 
to "Knife", leading to a lot of complaints and this debate.   Currently, you 
have to choose between logical grouping of items, or not breaking key combos.  
This proposal makes position and combo independant choices.

> 1) Pupmenu definitions will get an optional hotkey to activate this.
> This will be called a 'hotchar', which only resides within the context
> of the menu itself.

This is fine.  

> 2) The hotchars are not allowed to be a number, to achieve
> compatibility with the previous system, and to communicate to a user
> there's an additional method for choosing a menu item.
> 3) If a hotchar is available in a Pupmenu, it will be an additional
> choice for a user, the old convention to use number hotkeys will remain
> unchanged.

These two show the point you seem to be missing.  The hotchars and numeric 
position _should not_ exist together.  Having both does not solve the 
expandability problem.  You still can not insert a new menu item in the 
middle of a list without breaking key combos.  Additions have to be made to 
the end, no matter how they are related.

In the case of a well used key combo, the hotchar should explicitly be chosen 
to be the old number so the menu can be reorgainized and the combo doesn't 
break.  Hotchars should be numbers in ONLY these case. 
> 3) In the code we will usa a "%k" to indicate a hotchar, a menu string
> would look something like:
> "SPECIALS %t|Subdivide %kS %x1|Smooth Subdivide %ko %x2|Fractal
> Subdivide %kF %x3|Knife Subdivide %kK %x11|Merge %kM %x4...."

Your changing of the %k behavior is a fine, welcome addition.  
But you just broke the "W-4" combo (well, ok, I did it first).  That's what 
started this debate.   Knife belongs with  the other subdivides, but can't go 
there without breaking key combos.

Under my proposal as written (maybe not well written), that would be:

"SPECIALS %t|Subdivide (1) %kS1  %x1|Smooth Subdivide (2) %o2 %x2|Fractal 
Subdivide (3) %kF3 %x3|Knife Subdivide %kK %x11|Merge (4) %kM4 %x4...."

In this case, "Subdivide would be invoked by as "S" or a "1", "Smooth" by "o" 
or "2",  "fractal" by "f" or "3", "Knife by only "k", "Merge" by "M" or "4".  
The combo "W-4" is still mapped to the "Merge" function.

I assumed that all options other than "Knife" are "well used" and have combos 
that need to be preserved.  This would have to get determined on a case by 
case basis, but the default should be to add numeric hotchars to all existing 
items before inserting new features with only alphabetic hotchars.   This 
way, no key combos are broken.  

I also assumed that an item could have 2 hotchars, since it's just a LUT of 
key to event, but if we determine it is better to have only 1 hotchar per 
item, only the number would be kept in these cases, so the key combo is 

Yes, it breaks the "4th is 4" behavior.   But the whole point of keeping the 
numbers at all is to preserve user memorized behavior, so it really doesn't 
matter where they are on the list.  The people who are complaining about 
broken combos aren't counting down the list, they're just hitting keys from 
memory.    Don't sacrifice the behavior of the _app_ to preserve the behavior 
of the menu.

I don't think loosing the "4th is 4" behavior will cause an appreciable amount 
of confusion.  When users see an underlined "4" in the 5th item, they know 
what's going to happen if they hit "4", they won't bother to check our math.  
Following the convention I laid out assures we won't get completely scattered 
numbers, they will be in order, but will have items with no number between 

The _only_ time the strict "4th is 4" behavior would remain, is the case of a 
string that provides no hotchars for _any_ item.    It is just a fallback to 
allow us to impliment the code without having to track down every instance of 
pupmenu() in one sitting (there's ~146 of them).  If no hotchars were found, 
the LUT would be filled so ONEKEY maps to ITEM1, etc.  This means, that if 
you add an item with a hotchar to a non-updated menu, you need to add 
hotchars to _all_ items in that menu.

I hope this is clearer.
Robert Wenzlaff         rwenzlaff@soylent-green.com