On 07/28/2014 05:14 PM, Daniel Stone wrote:
the fact that our original design for the keyboard
interface started off with keysym events _only_ (not on mailing lists, I
don't think - was an in-person meeting a couple of years ago) but we
couldn't figure out a way to make it work, I'm pretty confident in this.
That is very useful to know.
A densely-packed index using keycode may be much more easy to use than
the sparse keysym enumeration. There are also bad keyboard definitions
where more than one key translates to the same keysym, so the
translation cannot be inverted. I would guess these are the reasons
behind the decision.
I would like to see character composition removed from xkb so that
western programmers are forced to use the input method, this would also
remove most of the code smell of having a per-client copy of the
xkb_state, and allow a preview of "dead keys". Not sure what to do with
legacy X applications that are not using the X input method, however.
I would also like to see consistency with other devices. Currently
everything that is not a "keyboard" produces identifiers that are more
like keysyms than keycodes. These should probably also produce a
densely-packed index number and an xkb mapping. The reason is devices
that wish to emulate keyboard keys (imagine the soft buttons that are
around the edges of drawing tablets). You could say that it is the
client's responsibility to handle this but this is just not going to
happen when the author of the software does not have an instance of the
device. But rather than the old method of faking keyboard events, the
device could just send it's own xkb mapping for it's buttons, the client
would work but have the capability of telling the events came from the
device.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
