Re: gtk+ keynav screwed (at least on win32)

[Owen Taylor <otaylor redhat com>]

Hans Breuer <hans breuer org> writes:

> Hi Owen et al.,
> over the weekend I tried to implement the recently missing
> bits in gdk/win32/gdkkeys-win32.c. 
> 
> Wed Feb 20 14:26:47 2002  Owen Taylor  <otaylor redhat com>
> 
> 	* gtk/gtkkeyhash.[ch]: Implement "fuzzy" key binding lookups;
> 	allow matches on key and level but not group. Also, implement 
> 	ignoring "consumed modifiers correctly."
> 
> 	* gtk/gtkaccelgroup.c gtk/gtkbindings.c: Convert to using
> 	GtkKeyHash.
> 	
> 	* gdk/linux-fb/gdkkeyboard-fb.c gdk/win32/gdkkeys-win32.c: Propagate
> 	doc and parameter name changes.
> 
> IMHO the previously code just worked fine (at least I haven't 
> noticed any pressing problems in this area) but now I'm stumbling 
> over the need of information possibly not even available via the 
> win32 api.

I've been seeing Tor commit extensive changes in this area in this
area over the last few days... I've only seen the ChangeLog but
the ChangeLog entries looked plausible.

The basic model of GDK is explained in the docs:

/**
 * gdk_keymap_get_entries_for_keyval:
 * @keymap: a #GdkKeymap, or %NULL to use the default keymap
 * @keyval: a keyval, such as %GDK_a, %GDK_Up, %GDK_Return, etc.
 * @keys: return location for an array of #GdkKeymapKey
 * @n_keys: return location for number of elements in returned array
 * 
 * Obtains a list of keycode/group/level combinations that will
 * generate @keyval. Groups and levels are two kinds of keyboard mode;
 * in general, the level determines whether the top or bottom symbol
 * on a key is used, and the group determines whether the left or
 * right symbol is used. On US keyboards, the shift key changes the
 * keyboard level, and there are no groups. A group switch key might
 * convert a keyboard between Hebrew to English modes, for example.
 * #GdkEventKey contains a %group field that indicates the active
 * keyboard group. The level is computed from the modifier mask.
 * The returned array should be freed
 * with g_free().
 *
 * Return value: %TRUE if keys were found and returned
 */

> If I understand gdk/x11/gdkkeys-x11.c correctly Gdk nowadays needs 
> to know in advance which key combinations will produce which 
> gdkkeyvals (group ??, level?) and vice versa.

The only information _gtk_ actually needs is what primary keys on 
the keyboard can produce certain keyvals; it doesn't need to know
the associated modifiers (which aren't in the GDK API) or even
the group/level 


> Especially unclear to me is the "consumed modifiers" idea/implementation.
> My understanding was that all modifiers needed to create the keyval
> are 'consumed' but apparently it doesn't work this way. 

The consumed modifiers are the ones that are used to determine the group
and level. On a typical European keyboard AltGR and Shift would be 
consumed modifiers. In the XKB implementation, the consumed modifiers
can depend on the key. For instance, For the "Print Screen" key
on a typical PC keyboard, Alt, not Shift controls the level.
(Alt+PrintScreen == SysReq).

But a fixed set of consumed modifiers for the entire keyboard should
be good enough.

Regards,
                                        Owen