Re: support for accelerators and bindings independant of current XKB keyboard language

[Owen Taylor <otaylor redhat com>]

Vlad Harchev <hvv@hippo.ru> writes:

>  Hi,
> 
>  I didn't try gtk-1.3.1 (but seems things didn't change in that respect), but
> there is a localization problem for all gtk-based applications, if they are
> used in environments that require support for several XKB keyboard languages
> (sorry, I don't know how to better name that thing) with respect to
> accelerators.
> 
>  Example: There is an accelerator Ctrl-F for some widget. It works fine if the
> current XKB keyboard language is "english". When user switches to some other
> keyboard language (say Russian, using Ctrl-Shift), pressing Ctrl-F doesn't
> work at all in the way it should be. The reason for that is that gtk uses
> keysym (that describes some string or character produced when pressing the
> letter in the given XKB keyboard language), rather than keycode (that
> identifies the key on keyboard, independant of current XKB language). As for
> other widget sets - QT apps use keycode (so accelerators work independant of
> the current XKB language), Win32's "widgetset" also uses "keycode", not a
> "keysym". Also, in gtk all keybinding for standard widgets (like Ctrl-A for
> "move to begining of line in GtkEntry") doesn't work after switching to 
> non-english XKB language. So, it's a big pain to use gtk-based apps, and this 
> should be fixed ASAP.
> 
>  So,  are gtk+ developers aware of this problem? (When) Are they going to fix
> it?

I'm not really sure what you are proposing.

An application that actually specified keycodes for accelerators would
be entirely incorrect. Keycodes are keyboard dependent, opaque
values. The application needs to specify Ctrl-F. It can't specify
Ctrl-41 because F will not have the value 41 on my system.

And, it would also be wrong to assume that Ctrl-F always maps to the
same keycode, even on the same machine. If I remap my keyboard so that
F is at a different place, then the accelerator should follow.

What perhaps _should_ be the case is that if you have a key where in
one keyboard group it maps to F, and in another keyboard group, it
maps to Cyrillic_a, then we should treat the accelerator C-F as
referring to both. Using keycodes internally to do the matching may be
part of the solution but there are additional things to worry about.

The problem that is actually harder to solve (and it is a problem that
GTK+ has now), is that you need to know that accelerators for 'a' and
'Shift-A' are distinct, but accelerators for 'plus' and 'Shift-plus'
are identical. (Note that '+' is unshifted on some keyboards, and
shifted on others.) 

Any use of keycodes certainly needs to be internal magic. I don't
think it makes any sense to expose keycodes to GTK+ applications.

So, I guess what I can say is:

 * Yes, we are aware of the problem and some other ones
 * If you have a proposal for a good solution, or a patch
   we'd most likely be willing to accept/apply it.
 * The constraints on the solution are:
   - It shouldn't expose keycodes to the app developer
   - It needs to handle existing sets of accelerators like
     the ones the GIMP has.

Regards,

                                        Owen

(As for the standard bindings, the way to solve that is to move
to binding-set for everything, and to use the same solution
for binding-set as for accel-group.)