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

[Vlad Harchev <hvv hippo ru>]

On 21 Aug 2000, Owen Taylor wrote:

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

  Yes, this is wrong approach, but it does work and makes all apps supporting
accelerators in any keyboard group correctly. But it's still a (very
useful to greeks and people from former soviet union) hack.
  It would be nice if that patch was applied to gtk-1.2.x though (and nice
solutions should be designed for gtk-1.3.1). Could you allow to include that
patch to official gtk-1.2.x tree? This way, all distributions will contain
the more cyrillic- and greek-friendly gtk. Even more, that functionality
could be activated only if some environment variable is defined (as I proposed
earlier) and/or automatically based on the current locale.

 As for gtk-1.3.x, I think that in order to  solve this problem, gtk should
introduce the concept "canonical keyval" (and provide its value as a member of
GdkEventKey) (it could be always lowercased also), so all apps that want
to handle key events directly for accelerators will use that value instead of
real keyval. Probably no concept of keycode needs to be introduced then (since
it was only useful for getting "canonical keyval" only).

 
> Regards,
>                                         Owen
> 

 Best regards,
  -Vlad