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

[Owen Taylor <otaylor redhat com>]

Vlad Harchev <hvv@hippo.ru> writes:

> > >  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.
> > 
> >   I meant this conversion to be performed in gdk_event_translate() of course.
> > 
> >   As for apps that really demand real keyval, I think the field 'guint
> > realkeyval' could be added to GdkEventKey that will contain the real keysym.
> > 
> >   I don't know whether the similar tricks possible for other ports of gdk.
> > 
> >   It may be still useful to introduce the gdk_keycode_from_keyval() and
> > gdk_keyval_from_keycode() too.
>> 
>  I composed a patch against gtk-1.2.5 and tested it with stock gnome from
> RH6.2. It works fine - accelerators like Ctrl-A work in GtkEntry independant
> of keyboard group and accelerators can be bound interactively to menu items
> correctly. Also, everything worked fine with gedit (^V as paste works
> independant of keyboard group and capslock's state).

I'm sorry for not replying earlier and saving you the trouble - this
second approach is completely unworkable. The apps need to see the correct
keysym. For instance, in GTK+-2.0 input methods are handled at the
GTK (not GDK) level, and of course, need the actual keysym pressed,
or you won't be able to input Cyrillic at all.

Plus, it's just fundementally the wrong approach. That's not
what a key symbol is.

Regards,
                                        Owen