alan@APPLE.COM (Alan Mimms) (09/12/89)
David (dshr@sun.com) responds:
Are you saying that you have more than 256 individual keys.
Or that, through an intelligent keyboard, you can generate
more than 256 codes representing key combinations?
Remember, X exposes a model of the keyboard that lets the
clients know the physical state of the keys that are visible
to the user, not the virtual state of a keyboard that some
software is emulating on a smaller set of physical keys.
David.
The problem really is that I'm attempting to make X live happily within
the confines of an already existing keyboard driver (the Macintosh
operating system). Users can use deadkey sequences to generate
characters for which they do not have "keys", but it would appear that
the simplest (in fact the only real) way to permit this is to make
X think I have a keyboard with keys for each possible character the user
can "type".
Since there are a LOT of these deadkey sequences, the resulting set of
KEYCODE values approaches (sometimes EXCEEDS) 256.
Aside from the above, though, isn't it a general problem with the protocol
that there is no way to have a truly large keyboard or a keyboard which,
through some magic of its own, pretends to be large. Asian character sets
are likely to bump their heads on a limit like 256 keys, I would think.
Any discussion sparked by this?rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/12/89)
Users can use deadkey sequences to generate
characters for which they do not have "keys", but it would appear that
the simplest (in fact the only real) way to permit this is to make
X think I have a keyboard with keys for each possible character the user
can "type".
Whether it is "simple" or not is perhaps subject to debate. The process
you are describing can more generically called an "input method" (using
multi-key sequences to generate a single "character"), of which there are
multiple styles. Far better to do this on client-side, where it can be
pluggable at the user's preference, says I.
Aside from the above, though, isn't it a general problem with the protocol
that there is no way to have a truly large keyboard or a keyboard which,
through some magic of its own, pretends to be large.
Depends on your point of view, I suppose. It doesn't seem like much of a
problem to me.
Asian character sets are likely to bump their heads on a limit like 256
keys, I would think.
An Asian character set, yes, but typically not an Asian keyboard. My
understanding is that most people have rejected building huge keyboards
as a bad idea. If you look at what's happening in Japan in the X environment,
for example, they're using a client-side approach (using a separate "server",
Jserver/Wnn, to handle the input method) to deal with Kanji. They aren't
doing this inside the X server.