keycodes all off by one with GTK and $DISPLAY pointing to an R5 server
otaylor at redhat.com
Sat Sep 17 15:39:28 PDT 2005
On Sat, 2005-09-17 at 01:28 -0700, Kean Johnston wrote:
> > For a start, if I remap a key with xmodmap, existing GTK apps
> > instantly use the new keysym. That implies that GTK doesn't have
> > keycodes hardcoded (GTK tends to pay little heed to specifications,
> > but it isn't that badly screwed).
> I didn't say it hard-coded keycodes, just that it *uses* keycodes,
> instead of keysyms. To be honest, I dont know which is the best
> approach. But the GDK code certainly has stuff in it that has
> very explicit knowledge of keysyms. To wit, gdkkeysyms.h,
> which lists most of they keys found in keysymdef.h but using
> different names (GDK_Home, for example, instead of XK_Home).
> There's certainly a great deal of voodoo going on in
> gdk/x11/gdkkeys-x11.c. So its less well behaved than you'd want.
> Of course, those codes havent changed in decades, so its more
> than likely safe, but I find whenever the same information is
> repeated twice, you're bound to run into trouble one day.
The keysym values are part of the X protocol. Not because they
are in events, but because they are keyboard maps. So, they can't
change and the assumption that GTK+ makes that X key symbols
translate identically into GDK key symbols (which are used on
all platforms with identical values, not just on X) is safe.
There certainly *is* a lot of voodoo in gdkkeys-x11.c, but it is
generally voodoo which is based upon research and upon the
X specifications (I'd hate to use the word "standard" to refer
to pre-XKB keyboard handling in X.)
As I indicated in my other mail, it's probably some bug in GTK+
or incompatibility with your keyboard map, but really impossible
to guess without seeing that keyboard map.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the xorg