Re: keycode handling

[Vlad Harchev <hvv hippo ru>]

On 2 Dec 2000, Havoc Pennington wrote:

 Hi,

 I'm very happy gtk development made step in this direction. This patch
establishes a framework for i18n-wise keyboard handling. I have the following
proposal to make gtk keyboard input i18n-friendly:

Problem:
 We international users who use non-latin1 language beside english, we have to
have several keyboard groups (as described in the Havoc's mail) and switch
them using some key combination. And one feature we want is ability to use
accelerators independantly of current keyboard group (i.e. pressing Ctrl and
key on which latin A is written (i.e. Ctrl-A) should move the cursor to the
begining of GtkEntry independant of keyboard group (and shift state aka
level)). Nonlatin1-friendly widgetsets like Motif and Win32 and QT already
allow this (i.e. accelerators work independant of the keyboard group and
level). It would be nice if GTK alredy was nonlatin1-friendly too.

Solution:
 I propose to extend GdkEventKey even further, by addition of the following
members (sorry, stupid names - suggest a better ones):
 gint	keyval_g0; 
 gint 	keyval_g0_l0;

 keyval_g0_l0 is keyval for key pressed with level 0 and group 0. I.e. it will
always contain lowercased latin letters (and other symbols). So, apps that
don't care about case of the pressed key and wanting to be i18n-friendly
should use this field instead of 'keyval' member.

 keyval_g0 is a keyval for a key pressed in group 0 and current level if there
are no general modifiers in effect (e.g. Control or Alt) and is a keyval for a
key pressed in group 0 and level 0 if there are general modifiers in effect
(e.g. Control or Alt) (this important, since if you press Capslock and then
press Ctrk-a, 'keyval' of X even will be 'A' and not 'a' - so lowering the
case for Ctrl-* or Alt-* combos is really useful). Most apps that have 
hardcoded keyvals should use this member instead of 'keyval' in order to 
work in any keyboard group.

 After having these 2 members added we have to urge apps to use keyval_g0
instead of keyval. We can use preprocessor to swap positions of 'keyval' and
'keyval_g0' members, e.g.:

struct _GdkEventKey
{
	... some members ...
#ifdef GTK_I18N_KEYEVENTS
	gint keyval_g0;
#else
	gint keyval;
#endif
	... some members ...
#ifndef GTK_I18N_KEYEVENTS
	gint keyval_g0;
#else
	gint keyval;
#endif 
	... some members ...
}
	Of course GTK itself should be compiled with GTK_I18N_KEYEVENTS
undefined. Thus, all apps will become i18n-friendly with respect to hardcoded
keysyms.

  Another task is to make accelerators working independant of keyboard group.
gtk_accel_group_activate, gtk_accel_groups_activate, gtk_binding_set_activate,
gtk_bindings_activate should be modified to check both keyval and then keyval
of the key pressed in group 0 to be i18n-friendly.

 After that, gtk would be i18n-friendly wrt keyboard input. But first step is
to add two additional members to GdkEventKey.

 What do you think about this?

> 
> Hi,
> 
> Attached patch adds the keycode to GdkEventKey and some functions to
> deal with the mapping from keycode to keyval and back. The main
> question here is whether the interface is implementable on other
> platforms; input from people working on GTK ports would be good.

 [...]

 Best regards,
  -Vlad