Jasper St. Pierre wrote:
It's because the keyboard is a surprisingly complicated tool with
multiple modes of operating, probably without you ever realizing it, and
clients need all of that power:
If I'm typing text, the *labels* of the keys matter, and input methods
allow us to translate sequences of key presses and releases into a
Unicode character on the screen.
We also have "chords", where holding down a certain key could affect
operation. For instance holding the "Shift" key causes the letters typed
to be capitalized. However, some users can't accurately hold down a
shift key, though, so we have accessibility support like latched keys
(press Shift, press "S"), and sticky keys (press Shift, press "S", then
press Shift again to turn it off).
If I'm playing a game, the *locations* of the keys matter. Games use a
WASD scheme not because the letters "W", "A", "S", and "D" mean
anything, but because their location on a QWERTY keyboard make a
left-handed arrow key shape. On alternate keyboard layouts, we still
need them to make that arrow shape, and not give users a layout where
going forward means you have to reach half-way across the keyboard.
We also have "key shortcuts", which combine both worlds: Ctrl+Z,
Ctrl+X, Ctrl+C, and Ctrl+V are all location-based, but Ctrl+F is word-based.
The typical approach, as done by Windows, OS X, and XKB (and now
Wayland) is to send the client an opaque integer that corresponds to "a
key", along with a map of how the keys are laid out, and then have the
client look up whatever information it needs.
This is not exactly true.
Windows + OS/X send a symbol that is much more like an X "keysym". There
are no scan codes. The driver has removed the layout information. If a
client wants key positions they must back-translate the keysym by using
a different api to determine the hardware and what location on it
produced each keysym.
And sticky keys and so on are done by the driver. The client can see the
shift keys being pressed, and perhaps deduce from this the sticky key
setting, but they don't have to, as the shift flags are set correctly on
the key event.
All text should go through the input method. This would consume
keystrokes and may use it's own surfaces (as Chinese input does), and
occasionally spit out piece of UTF-8 that the client inserts into the
typed text. The client never looks at key events for this. It looks like
about 90% of the complexity of XKB is to produce symbols for European
languages, including dead key compositing. This should all be scrapped
so that clients are forced to use the input methods.
And you seem to be doing some bikeshedding, such as saying that Ctrl+Z
is "location based". Yes, that is why the Ctrl+Z combination was chosen.
However NOBODY types the lower-left key. They type the key with the 'Z'
on it, or they use an api to change what letter the shortcut is and type
that letter.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
