Robert Currey wrote:
I do think that this goal is achievable, because the Alt-Numpad
functionality is so limited: all it does is to generate the same symbols
without regard to any codepage, keyboard mapping etc. And that's what
makes it useful im some cases (see below). And exactly because the
functionality is not supposed to be flexible at all, I think that it
doesn't necessarily conflict with the X paradigm.
To play nice, this should only need xkb file interpretation changes
(changing the way the code works may get messy).
I'm not that hip on how XKB maintains "state", but for Alt-gr type combos it
is at least close.
Unfortunately it is not possible to implement this functionality solely
based on xkb configuration. It would definitely need some modification
of xkb and I'm hesitating to go the xkb route because of the expected
"messieness" and the fact that the functionality does not fit very well
with the concept of xkb. Xkb deals with a limited set of states (levels,
groups) whereas Alt-Numpad needs a large number of states (all possible
three-digit combinations).
ummm ... the "to be transparent" is true for windows, but obviously not for
unix or mac or ...
This really smells like an input method ...so your app that needs to play
with "readers for Smartcards or keyboard-wedge style barcode readers" would
need to support the input method.
The problem here is that it will not be possible to change those
applications: one application are sessions running in a
terminal-emulation for IBM mainframes which just expect the data to be
scanned or read from the smartcard to be "typed" into existing input fields.
Joerg Henne
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
