Re: [gtk-list] gdkkeysyms.h question

[Havoc Pennington <hp redhat com>]

On Thu, 16 Sep 1999, Andreas Leitner wrote:
> --					keyval			state	
> WinNT remote via X-Win32:
> pressing TAB				GDK_TAB			0
> pressing SHIFT-TAB			GDK_KP_TAB		1
> 
> SparcStation 10:
> pressing TAB				GDK_TAB			0
> pressing SHIFT-TAB			GDK_TAB			1
> 
> Linux (x86/Debian):
> pressing TAB				GDK_TAB			0
> pressing SHIFT-TAB			GDK_ISO_LEFT_TAB	1
> --
> 
> This isn't exactly what I expected. Now I don't know much about how X
> works, but shouldn't such situations be avoided in a high level library
> (GDK is supposed to be a higher abstraction on top of X or any other
> windowing system, is it?)
> 

This is actually due to a high-level abstraction.

X has a concept of a "keymap." A keymap maps physical keys or key
combinations to "keysyms," where keysyms are a higher-level concept. 
The tab key on my keyboard is represented by the keycode 0x17, for
example. My keymap (Debian system) maps this to the GDK_Tab keysym
normally, and GDK_ISO_Left_Tab when shift is held down. Users can change
the keymap at will; for example, I always swap my control and caps lock
keys. Use "man xmodmap" and the "xkeycaps" program to explore this 
arrangement. Also, the Xlib Programming Manual by Nye has info on it.

Normally X sends key codes to applications. However, key codes are
useless; they are just raw data from the keyboard and hardware-dependent.
So GDK automatically converts them to keysyms using XLookupString() and
places the keysym value in the GdkEventKey.

Moreover, it is always wrong to use keycodes, because you destroy the
keymap; you can't know which keycode is labelled "Tab" on the user's
keyboard, and you can't know if for example I've swapped control and caps
lock, etc. 

The "state" field is different, it's a bitfield that can have
GDK_SHIFT_MASK, etc. set, according to the number of modifiers. It's
appearing as "1" because GDK_SHIFT_MASK happens to be 0x1. 
See my book for details on how to check this field, etc.:
developer.gnome.org/doc/GGAD
Note that you should use the state rather than the keysym to determine
whether shift was pressed, it's just a coincidence that some keymaps map
shift-tab to a different keysym.

So to solve your problem you probably want to use both Tab and
ISO_Left_Tab as in gtkwindow.c. Apparently GDK_KP_Tab should also be in
this group. Presumably some workstations in the past had different keys
for these different tabs, and that's why there are multiple keysyms. Then
the various X server vendors on PC keyboards set up the defaults
differently.

Havoc