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



On Mon, 14 Aug 2000, Vlad Harchev wrote:

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

 Could anybody comment on this? Would you also accept the patch fixing this? 
 My thoughts are that additional field 'keycode' should be added to
 GdkEventKey struct, support for converting keyvals to keycods and back
(keycode to multiplie keyvals apparently) - these are changes for gdk, and
 gtk's accelerator handling code would be changed too to consider keycodes 
 rather than keyvals. 

 Thanks.

 Best regards,
  -Vlad






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]