Re: key themes (cont.)

[Tom Tromey <tromey creche cygnus com>]

>> As I understand it, we can't just randomly introduce new keysyms.
>> So, e.g., we couldn't make one called "cancel" that we could then
>> bind to cancel a dialog.

Patrick> Why can't we introduce new keysyms?  OSF did (for Motif).
Patrick> Admitted, I'm not an expert on what is involved, but I do
Patrick> know that there is some facility inherent in X whereby we can
Patrick> bind arbitrary text to a particular keycode.

OSF did, but that was a mistake on their part.

Patrick> My real point is that the issue of keybindings is something
Patrick> that, by rights, should happen at the X layer (or other
Patrick> display abstraction layer if that idea every happens.)

Obviously the X designers disagree with you.

In principle I agree with you.  But then, I also think that X
generally works at the wrong level of abstraction.  I much preferred
NeWS (moment of silence here).

But that's neither here nor there.  Gnome's remit doesn't include
fixing X.  Instead we should just work with what we have, even if we
think it is flawed.


The gory details:

In X, pressing a key generates something called a keycode.  The
keyboard->keycode mapping is magic and unchangeable (without hacking
the server).

Keycodes are mapped to things called keysyms by the server.  This
mapping is global, so changing it changes all clients.  When you use
xmodmap or xkeycaps, you are changing this mapping.

Roughly speaking, a keycode corresponds to any key on the keyboard
(e.g., right shift key), while a keysym corresponds to some
higher-level translation of a given chord (e.g., right shift key and
`a' key means "keysym A").


So as you can see, keysyms still correspond to a relatively low-level
operation: that of pressing a key.  As far as I can tell there is no
way to tell X to map a sequence of keycodes onto a keysym (unless the
keycodes include modifier keys, like shift); this means that Emacs
keybindings could never be emulated at this level.

A more sinister problem is that, since the keycode->keysym mapping is
global, adding new keysyms and our own magic translations will break
existing applications.

For instance, if we somehow made a new "cancel" keysym and bound ESC
to it, then pressing ESC would always generate a "cancel" keysym.  So
for instance you wouldn't be able to leave insert mode in vi, because
xterm wouldn't know that "cancel" really was ESC.


This is just a long-winded way of saying that the key binding code has
to be in the individual applications, and can't be stuck into the
server somehow.

This is no big deal.  We write a library to handle it, plug it into
our apps, and we're done.  Apps with new actions to register just call
into this library.

Xt has already solved this problem, btw.

Probably the library needs to be integrated with Gtk to some degree.
I say this because the text and entry widgets are going to need key
bindings.

There are probably some tricky sub-problems to solve.  Hopefully I'll
remain ignorant of the details... :-)

Tom