Re: uline accels, aka. mnemonic activators

[Owen Taylor <otaylor redhat com>]

Hi Tim,

I would agree with you that mnemonic's and menu accelerators are
somewhat different:

 - Mnemonics have different conflict resolution behavior
 - The dynamic-accelerator-changing code in GtkMenu isn't necessary for mnemonic.

But in essence, GtkAccelGroup is just a fancy hash from keyval/modifiers
to action, and that's what we need for mnemonics. I don't think
introducing a separate, unrelated mechanism for mnemonics is
less confusing or simpler.

>From the point of view of the average programmer, GtkAccelGroup actually
looks very simple:

 - Create an accelgroup
 - Connect keyval/modifiers to actions within that accelgroup
 - Attach the accelgroup to a toplevel, to add those keyvals/modifiers
   to set of keys that are handled globally on the window.

This same high level view makes perfect sense for mnemonics as well.

So, all we need is a global toggle indicating whether this accel
group holds mnemonics or menu accelerators. Sure, this internally
complicates the accelerator group a bit, but you certainly
arent' scared of a little implementation complexity ;-)

The other possibility would be to have gtk_accel_group_add_mnemonic() 
and make the distinction a per-entry thing. Perhaps that would
seem a bit simpler than having separate accel groups with a
global behavior toggle.

The point here is keeping the number of independent unrelated concepts
that the programmer needs to know to use GTK+ to a minimum.


Other reasons for using accelerator groups instead of making up
a new concept:

 - To properly handle keyboards with multiple groups (say, a Russina
   keyboard) need to be doing somewhat sophisticated resolution
   of key presses. 

   It would be better not to duplicate this code more than possible,
   and furthermore the resolution can be done better the more you
   know about what accelerators are available. For instance,
   on a US keyboard, you might want to treat <Ctrl>= as the same as   
   <Ctrl>+ if only one was bound to an accelerator, but separate
   them if both are bound.

 - Enhancements like per-entry data are also needed for GtkAccelGroup
   and we shouldn't have to keep changing both APIs in parallel.

 - For GtkPlug, I need to keep track of _all_ globally trapped 
   keystrokes and forward them to the parent GtkWindow.

So, yes, mnemonics are somewhat different from menu accelerators, 
but in the end, they are globally trapped keystrokes, GtkAccelGroup
is how we handle globally trapped keystrokes, and I don't think
it makes sense to introduce a new parallel mechanism.

Regards,
                                        Owen