Re: Emulation of Alt+Numpad+Digits behavior

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