Re: unmodified accelerators and _gtk_window_activate_key()

[Tim Janik <timj gtk org>]

On Sun, 28 Dec 2003, Owen Taylor wrote:

> Notes:
>
>  - In order to change the order of key press processing, you
>    need to figure out how that relates to the XEMBED protocol,
>    or Plug/Socket won't work correctly.

if the plug/socket code duplicates the gtk_window_key_press() logic, it
probably needs to be adapted as well. other than that, giving precedence
to normal letters for the focus widget is unlikely to interfere with xembed
accelerator processing, as it causes the embedded widget to receive more
key presses, rather than less. at least i don't see how that'd have bad
effects, if you have specific problems in mind, please let me know.

>  - The single letter rule seems rather arbitrary to me.

the emphasis was on non-modifier keys. what makes them special is
that we have widgets like GtkEntry or GtkTextView that make
extensive use of them, giving those used for accelerators precedence
over entering text really makes no sense for these widgets.
i think that's a pretty valid rationale, rather than just some
arbitrary idea.

>  - Having behavior different in different apps seems
>    highly confusing to the user. (Re: your b) solution
>    of allowing the user to replace the key press
>    handler with one with a different ordering.)

it definitely is highly confusing to users to be able to type
certain letters of the alphabet in an entry and others not.
so making that work for some applications is an improvement,
even if there are still others that behave differently and
remain buggy for a longer period.
apart from that:
1) it is already possible to completely alter key processing in
   windows by overriding the GtkWindow handler or connect to the
   ::key-press-event signal. so if you were on a quest to unify
   all gtk application key processing behaviour, you'd already lost.
2) consistency is a pretty bad argument to be used against
   client side bug fixes. users hardly insist on all applications
   being unusable in an aspect if they encountered that aspect to
   be broken for a single one.
3) effectively, _gtk_window_activate_key() can already be used by
   linux clients, due to a libtool bug causing _gtk_* functions
   to still be exported. all i'm asking for is to give that use
   official blessing and make that bug fix portable across linux,
   because there is a factual need for this.


>  - Your proposed changes don't appeal to me much, because
>    they fix your problem, while still leaving us having
>    to answer everybody else's complaints in this area
>    (these are:
>
>     - emacs keybindings don't really work because they
>       conflict with the normnal accelerator space.
>     - there are considerable problems with input methods
>       that have keybindings that conflict with the
>       normal accelerator space.
>    )

i don't think these are entirely the same problems, and as a consequence,
i'm not following your conclusion that they may be only fixed at once.
the key bindings have different priorities for tasks like text writing:
1) normal letters, digits, and similar characters, as well as movement
   primitives (cursor keys, backspace, delete) have priority over
   everything else
2) input method keybindings that conflict with the normal accelerator
   space but are vital for entering locale specific text need to
   have priority over accelerators
3) emacs keybindings (as well as accelerators) are a convenience issue.
   for two users both using this binding, one might expect <alt>+f to
   pop down the _File menu, while the other might expect the action
   forward-word to be taken.
   that can happen due to different levels of familiarity with emacs
   keybindings, or even based on what task the user currently focusses on.

here, (3) looks like a hard to resolve conflict (if at all), while for
(1) and (2), precedence should definitely be given to the text processing
widgets.

> I'd be really, really inclined not to make any changes here
> before 2.4...

i consider the current situation wrg (1) and (2) to be unacceptable.
(1) is a show stopper to non-modifier accelerators or to text processing
for applications already using those accelerators in the same accelerator
scope as text widgets. (2) is a show stopper for all kinds of accelerators
and localized text processing.

for (1), it could have been good enough to just export
gtk_window_activate_key(), so applications that employ non-modifier
accelerators are able to unbreak text processing by giving it the proper
precedence over accelerators.
but for (2) applications can't be expected to hack around this breakage
because programmers hardly know input method specific key bindings.

so i (and probably a couple users out there) rather not wait another year
or longer for these issues to be fixed.
i've already made a siggestion to fix (1), for (2), is there a way we can
query X for the relevant key bindings, so we can give precedence to them?
if that is not the case, the only possibility i see currently is to give
the focus widget full priority over accelerators and mnemonics (and that
is non trivial if accelerators and mnemonics are meant to still have
priority over GtkBindings on the focus widget). that'll break some
convenince bindings (accelerators aren't anything more than that
really), but it does ensure that accelerators don't cause fundamental
functional breakage.

> Regards,
> 					Owen
>

---
ciaoTJ