Modifier mapping and shifted modifiers

[Adrian Robert]

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