Howto handle modified keys

[Glynn Clements]

Thomas Dickey wrote:

> > identify modifier bits is to check which keysyms are associated with
> > the modifier bits. E.g. if mod1 is associated with Alt_L and/or Alt_R,
> > then mod1 is the Alt modifier. Use XGetModifierMapping and
> > XGetKeyboardMapping to determine the mapping between modifier bits and
> > keysyms.
> > 
> > Note that, historically, the key labelled Alt tended to correspond to
> > the Meta modifier rather than the Alt modifier.
> 
> That's imprecise: something like "the modifier associated with the Meta
> keysym" is closer.

It's more verbose; I'm not sure that it's any more accurate.

FWIW, the intrinsics documentation uses the terms "Meta key modifier"
etc, as opposed to "Shift modifier" etc for the hardcoded modifiers.

Although Xlib itself doesn't name any modifiers beyond Shift, Control
and Lock, the modifier names Alt, Meta, Super and Hyper are known to
the intrinsics (Xt) and can be used in translation tables passed to
XtParseTranslationTable(), where they will be interpreted according to
which keysyms are associated with the modifier bits.

Regardless of terminology, the point remains that the behaviour
associated with the Mod1 through Mod5 bits should depend upon the
keysyms which are associated with those bits. Hard-coded associations
with specific bits is a bad idea, in the same way that hard-coded
associations to specific keycodes regardless of the keycode->keysym
mapping would be.

BTW, the ICCCM also stipulates similar handling for the Lock modifier:

	The Lock modifier should be interpreted as Caps Lock or Shift
	Lock according as the keycodes in its controlling set include
	XK_Caps_Lock or XK_Shift_Lock.

The difference between the two is that Shift Lock applies to all keys,
while Caps Lock only applies to those corresponding to alphabetic
characters, e.g. (assuming a US keyboard):

	neither:	q w e r 1 2 3 4
	Caps Lock:	Q W E R 1 2 3 4
	Shift Lock:	Q W E R ! @ # $

-- 
Glynn Clements <glynn at gclements.plus.com>