[Bf-committers] Pupmenu conventions. (Was: CVScommit:blender/source/blender/src
edit.c)
Douglas Toltzman
bf-committers@blender.org
Thu, 9 Oct 2003 13:15:14 -0400 (EDT)
This discussion seems to be running in circles. At the risk of repeating
what Robert has already said several times. In an attempt to clarify the
desired logic, here goes nothing;
The menu text for all Blender menus should be defined as a program
resource (as in most modern GUI systems) to support flexibility and
national language translation. As in MS-Windows, a special character such
as ampersand would be specified as a marker for the menu handling function
that would signal that the following character specified the key-stroke
that will select that menu item. The menu item would also have a numeric
code association with it that would be returned to the caller or posted in
an event to indicate, without ambiguity, the command that should be
executed.
The menu handler code would then be responsible to read a menu resource
(however it is stored) as a numeric identifier followed by an ASCII
string. The menu hander would scan the ASCII string for the special
character. If the special character is found, an entry is added to table
that correlates the character following the special character with the
numeric code of that menu item. That character is also highlighted
(underlined, etc.) in the menu to visually indicate to the end user what
character is associated with the respective menu item. I'm going to call
this character the "activation key".
To activate a menu item, the end user clicks on it with his/her mouse, or
hits the activation key associated with that menu item. Once the user has
made a selection, the menu processing code returns the numeric result
association with the selected menu item.
The only restriction this places on the menuing system is that no two menu
items can use the same activation key. Regardless of which language is
used for the menu items or which order the items are placed, the numeric
result of a menu selection can remain constant.
The logic is very simple, portable, and consistant with many other GUI
interfaces. The current numeric assignments will simply be included in
the legacy items as their activation key.
A menu might be defined as follows to be compiled/loaded by the menu
processor (assume that ampersand is the marker character);
2001 Old Menu Item &1
2002 Old Menu Item &2
2010 New &feature
2003 Old Menu Item &3
Now, if the user presses "3" after this menu pops up, the menu handler
returns 2003, regardless of the sequence of menu items. The new feature
can be activated with "f". It is also obvious to new users which keys
will activate which menu items. This menu can be recoded in many
languages in any sequence and, even with different activation keys, but
the result code returned by the menu handler will always be consistant.
Of course, if a user mouse-clicks on a menu selection, the code for that
selection is returned in the same way as if the user pressed the
activation key. Some menu items may not even have an activation key, in
that case, the user would have to select it with his/her mouse.
Note: program resources could be declared in the code for simplicity. By
creating a single file for all of these resources, NLS becomes relatively
trivial. Forgive me if such a system already exists, because I've not
spent any time in the code for the blender UI.
On Thu, 9 Oct 2003, Ton Roosendaal wrote:
> Hi,
>
> I am not against changing order in menus.
>
> Menus only have to be logically structured, and if possible remain
> compatible with older versions.
>
> In the Snap Menu, which was a SNAP CURSOR menu, the new 'selected to
> centre' option can logically and consistantly put to the end, also to
> reward the old convention. It was even doubtful if the option belonged
> there...
>
> Such decisions, as I said before, can just be looked at at a per case
> base. And I doubt there are many cases we should reward old conventions.
>
> -Ton-
>
>
>
> On Thursday, Oct 9, 2003, at 16:10 Europe/Amsterdam, Robert Wenzlaff
> wrote:
>
> > 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
> > preserved.
> >
> > 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
> > them.
> >
> > 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
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://www.blender.org/mailman/listinfo/bf-committers
> >
> >
> ------------------------------------------------------------------------
> --
> Ton Roosendaal Blender Foundation ton@blender.org
> http://www.blender.org
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>
/*********************************************
* Douglas Toltzman
* President/CEO, Oak Street Software, Inc.
* doug@oakstreetsoftware.com
* http://www.oakstreetsoftware.com/
*********************************************/