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

Roel Spruit bf-committers@blender.org
Thu, 9 Oct 2003 22:58:40 +0200

I don't know your lofic, but the shift-s menu was divided into a "Selection
to...." section and a "Cursor to..." section.
because the new snap method snapped the SELECTION to a certain place, it is
not very logical to put it at the end.


-----Oorspronkelijk bericht-----
Van: bf-committers-admin@blender.org
[mailto:bf-committers-admin@blender.org]Namens Ton Roosendaal
Verzonden: donderdag 9 oktober 2003 17:09
Aan: bf-committers@blender.org
Onderwerp: Re: [Bf-committers] Pupmenu conventions. (Was:
CVScommit:blender/source/blender/src edit.c)


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

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.


On Thursday, Oct 9, 2003, at 16:10 Europe/Amsterdam, Robert Wenzlaff

> 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

Bf-committers mailing list