[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Modifier mapping and shifted modifiers
From: |
Adrian Robert |
Subject: |
Modifier mapping and shifted modifiers |
Date: |
Wed, 03 Nov 2004 21:12:41 -0500 |
Hi developers,
I would like to add a new default for X back-ends relating to the
modifier mapping.
The default is called "GSModifiersAreKeys" ("GSModifiersIgnoreShift"
is a possible alternative) and would be documented as (immediately
following the descriptions of GSFirstCommandKey and friends):
On some keyboards, the default X11 mapping includes keycodes
that are mapped to one or another modifier keysym depending
on whether 'shift' (or in some cases, another key) is
pressed. This is the case on some Apple USB keyboards for
example: a key on the left side of the spacebar maps to
"Option" without shift pressed, and "Alt" with shift
pressed. Such keyboard mappings are often useful in
non-English contexts to access accents or non-Roman
characters. However if such a key is used as a modifier in
GNUstep problems can occur when trying to use the modifier
in conjunction with a shifted character. In particular, you
will need to hit and release the modifier and the shift key
in a particular order, or else things will not work as
expected. If you experience such a problem (the modifier
will not work all the time, or will become "stuck"), set
'GSModifiersAreKeys' to YES.
The Explanation
A while ago I posted and eventually checked in a patch to X backends
to determine modifier state based on keysyms rather than keycodes.
This is the way other X applications do it and it helped GNUstep
integration on platforms where people use xmodmap or other means to
map multiple keys to the same modifier. Moreover more than two keys
could be used for a modifier. However a problem arises in this case
with keyboards that require you to hit 'shift' to access a
particular modifier. For instance, many Apple USB keyboards (which
can be used under linux) have an 'alt' key accessed by
'shift-option'. Both are reported as the same keycode, but
different keysyms. The result is X reports one modifier if shift is
down, a different one if it is not, so that if both keys are down
the result depends on which order they were pressed in. Likewise
for the release.
This was causing undesired behavior (apparent inconsistency and key
"sticking") for some people, so I added code that partially
mimics the old keycode-based assessment to avoid this. When
activated this code tells GNUstep to ignore the 'shift' and other
modifier state when determining the modifier associated with a key.
The upshot is you cannot get a shifted modifier into GNUstep (though
separate processing such as XIM servers still work), but you avoid
the "sticking" while still using keysym-based modifiers for keys
where 'shift' doesn't make a difference.
If no one has any objections, I'd like add this default. (The code in
XGServerEvent.m to obey it is 3 lines.) But, I realize there is a
general preference to avoid additional defaults if possible. Two
alternative solutions without adding a default are:
- set the behavior as if it were 'YES' (should this be the default
even if it is settable?)
- revert completely to the old keycode-based method
- Modifier mapping and shifted modifiers,
Adrian Robert <=