Re: support for accelerators and bindings independant of currentXKB keyboard language

[Vlad Harchev <hvv hippo ru>]

On 19 Aug 2000, Owen Taylor wrote:

> 
> 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.

 In fact, I didn't propose how to solve that problem :)
 
> 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.

 Of course programmer shouldn't have to deal with keycodes directly. 
 
> 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.


  The problem can't be solved if gtk won't deal with keycodes internally, of
course. I propose addition of the following functions to gdk:
	/*this calls XKeysymToKeycode*/
	guint gdk_keycode_from_keyval(guint keyval);
	/*this uses XKeycodeToKeysym*/
	guint gdk_keyval_from_keycode(guint keycode,guint index);

 Also, the field 'guint keycode' should be added to the following structs:
 GdkEventKey, _GtkBindingEntry, _GtkAccelEntry.
 
 Prototype of no function needs to be changed - all functions that deal
with the modified structures should get the value of keycode theirself (e.g. 
gboolean    gtk_bindings_activate           (GtkObject *object,
                                             guint keyval,
                                             guint modifiers);
  - this function will get the keycode value itself using, so there is no need
to change its prototype).
 I think this change won't break binary compatibility (since very few programs
manipulate with _GtkBindingEntry and _GtkAccelEntry directly).

 As for exposing keycodes to applications - I think this exposure is
necessary, at gdk level using 2 functions I described. Keycodes could be
useful for app writers too, I think (but for very specific purposes).

 What do you think about this proposal? Does it satisfy constraints listed?

 Another variant would be the following:
 No new members or functions are added, but 'keyval' in GtkEventKey is always
 set to the keysym corresponding to the keycode of the real X event in the 
 latin-1 keyboard group (while 'string' containing the real string). I.e., 
 when the real keysym should be, say, Cyrillic_a (as Returned by XLookupString)
 , the keyevent->string is set to the string returned by XLookupString,
 but the keyval is set to 'f' (latin set), not the Cyrillic_a. This won't break
 any existing apps at all (since gtk's keyvals are not defined to mean something 
 particular, so they don't use it). The only use of keyval different from 
 comparing to some  hardcoded value (like GDK_Up) is in gtkinputdialog.c for 
 producing visual string for state+key combination - but its behaviour with 
 this hack is more desireble than without!. Probably review of gtk code would
 be necessary (just a 'grep keyval' :) to check that this hacklish solution 
 won't hurt anything.
 
 
> 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.)

 I didn't understand what you meant here.

 Best regards,
  -Vlad