Re: keycode handling

[Owen Taylor <otaylor redhat com>]

I agree that we need to figure out how to make this functionality
easily accesssible to programs not using GTK+'s accelerator
mechanism. I'm not sure I would exactly do it as you suggest:

 - There is no reason to add extra fields to GdkEventKey - if additional
   computed keyvals are wanted, they can be done as accessors

    guint gdk_event_key_get_base_keyval (GdkEventKey *event);

   Or something.

 - Magically renaming the fields of the GdkEvent using #defines
   is not something I generally would consider conducive to
   the future maintainability of GTK+.

But more generally, I'm not sure that the algorithm of simply
using group zero is right, and I'm not even sure that we 
can decide the best algorithm right now, so we may want
to hide that from the programmer.

The simple case is - 

 Accelerator: <Control>A
 Activated:   Whenever <Control> and the key with 'A' (and maybe
              other things) printed on it is pressed.

But what about:

 Accelerator: <Control>{

I can produce the { character on my keyboard as:

 <Shift>+[   [ G=0, L=1 ] 
 <AltGr>+7   [ G=1, L=0 ] 

Clearly, this should be activated when <Control> + either
of those two combinations is pressed. But I probably would
not expect it for <Control>+7


Or, 

 Accelerator: <Shift>+

[ Found in GtkCTree as a keybinding ]

The expectation of the person writing this was the user had a US
keyboard:

 /---\ /---\ 
 | _ | | + |
 | - | | = |
 \---/ \---/  

But the keyboard in Germany, looks more like:

 /---\      /---\ 
 | * | ...  | _ |
 | + |      | - |
 \---/      \---/  

[ Suprisingly, the CTree was written by Germans.... ]


With the German layout, should the accelerator be activated
for '+' or <Shift>+ == '*'?

I think the answer here is that the binding should be fixed
to be simply '+', not '<Shift>+'

But if the correct binding is '+', should that be activated
when the user types '='? Does that depend on whether there
is another binding explicitely for '='?  

(If the answer to that is yes, remember that keys can be
handled in various different layers.)


Thise isn't at all trivial, and I don't think simply mapping
to some sort of 'canonical keysym' that people are supposed to
use when writing key symbols is the correct approach.


My current best thought is to suggest people write something
vaguely like:

  static GdkAccelMap *map = NULL;

 if (!map) 
   {
     map = gdk_accel_map_new (NULL);

     gdk_accel_map_add_binding (map, "a",         GUINT_TO_POINTER (ACCELERATE));
     gdk_accel_map_add_binding (map, "<Shift>a",  GUINT_TO_POINTER (DECELERATE));
     gdk_accel_map_add_binding (map, "+",         GUINT_TO_POINTER (ZOOM_IN));
   }

 switch (GPOINTER_TO_UINT (gdk_accel_map_lookup_event (map,event)))
   {
   case ACCELERATE:
     [...]
   case DECELERATE:
     [...]
   }

Yes .... more API. And we could use the same GdkAccelMap internally
in GtkBindingSet, GtkAccelGroup, and even for Havoc's GtkIMContextSimple
modification.

Regards,
                                        Owen

Vlad Harchev <hvv hippo ru> writes:

> 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
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list