Re: uline accels, aka. mnemonic activators

[Tim Janik <timj gtk org>]

On Sat, 17 Mar 2001, Tim Janik wrote:

> On 16 Mar 2001, Owen Taylor wrote:


> i'm sorry, but data extensions for accel groups would break serialization.
> accelerators are in place to "activate" a widget argumentless, we sat down
> at some point to cover more sophisticated keybinding setupd, and GtkBinding
> steemed out of that. if we're missing globally parameterized key bindings,
> that's (which we do) to be fixed on the GtkBindings side.

that was meant as "(which we don't)".

also, while evaluating this, GtkBindings isn't really _that_ suitable,
while we could support per-widget (not just per-class or per widget path)
binding sets, optionally supporting dialog global invokations, it's hard
to shift a mnemonic_group boolean in (and _add_path wouldn't make sense
API wise either).

though binding sets at least support additional signal arguments, accel
groups are much worse. despite the many more API inconsistencies that get
introduced by trying to handle mnemonics from accel groups, the issue
of passing additional signal arguments is much worse there (i,e, the
API doesn't account for that, and they couldn't be serialized). accel
groups where simply designed around a fixed non-parameterized signature,
are recommended to be bound to ::activate (and that's also what we do
automatically for newly introduced accels from menurcs) and only need
to exist in the first place because we support runtime changes and
propagation of accelerators.

mnemonics are wrong to put there, which is why our visibility probloems
arose in the first place, and why we have bad hacks like a menu's internal
uline accel group (plus a window's default accel group) and why we can't
support non-modifier keyvals in menus that support uline accels, why we
have oustanding bugs like pressing an Alt+UlineAccel combination on a
menu item acts like <backspace> etc. etc. etc.

if we proceede this path of conceptual blourance, we'll never
1) get the current negotiation fixed
2) confuse people with inconsistent API (what means GTK_ACCEL_VISIBLE
   for an uline accel? why can i unlock it?)
3) confuse people with accel groups expecting a (widget,bool,data)
   signature for conflicting uline accels, while supporting (widget)
   otherwise
4) can't support extra data arguments for uline accels either
5) a bunch of other problems that i'm not currently aware of (they are
   out there, that i'm sure about)


> > 
> > Regards,
> >                                         Owen
> > 
> 
> ---
> ciaoTJ
> 

---
ciaoTJ