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

[Vlad Harchev <hvv hippo ru>]

On Mon, 21 Aug 2000, Vlad Harchev wrote:

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

 After some research and talks with XFree86 developers (namely Ivan Pascal
<pascal@info.tsu.ru>) it's turned out that XLib's XLookupString from XFree86
and from x.org supposed to do (contained code for) exactly the same as my
patch did (only when control modifier is active) - but due to a stupid bug
(that was fixed recently) it works now in XLib for XFree86-4.0.1.

 As I was told, that logic can be seen in implementation of XLookupString at
the end  of xc/lib/X11/XKBBind.c and it's very clear to understand. So, why
gdk can't do what XLib is allowed to do with key events?

 So, I propose the addition of the member 'real_keysym' to GdkEventKey that
will contain the real keysym of the X event. The 'keysym' will be equal to
'real_keysym' when 'mod1' and 'control' are inactive (i.e. the plain typeing,
not key combinations, will preserve keysyms). In all other cases 'keysym' will
be equal to keysym of the pressed key in the 0th keyboard group (thus it will
be lowercased - making software written by lazy programmers that don't
convert keysym to lower work independant of the state of 'capslock').
 To be even more generic, I think it also would be better to add another
memeber 'normalized_keysym' that will always contain a keysym for the key in
0th keyboard group, so that handlers for key_press_event will use only that
value (if that code pretends to be correct). Otherwise (if only 'real_keysym'
member is added) accelerators without modifiers (like 'p') won't work when
another keyboard group is active.

 What do think on this?

 Best regards,
  -Vlad