mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (09/13/89)
> From: SUN.COM!dshr@bloom-beacon.mit.edu (David Rosenthal) > To sum up, the way to change the way keys are interpreted is to > change the clients. Persuading the server to lie to its clients > about the state of the keyboard is a very bad idea. > From: rws@expo.lcs.mit.edu (Bob Scheifler) >> So you would put code into every single client to individually >> interpret Num Lock? > Yes. >> If a piece of hardware had a key marked "Shift" that just sent a >> keycode, surely one would diddle the server to remember state and >> shift a to A. > No. Interpretation of Shift and Lock (and Control and ...) is > already done on the client side, not in the server. > From: David Rosenthal <dshr@sun.com> >> Well, what if the manufacturer of this workstation didn't build the >> shift lock key into the hardware or the kernel in a useful manner. > There is no need to build code into the kernel or the server to > imitate a locking shift key if no such key exists. "Just the facts, > mam" is all that X needs. Perhaps, but the Sun sample server from MIT does exactly that: the server fakes a locking key for any key that's tied to the Lock modifier. (I find this very annoying. When I come up with a scheme that I think is better than what's in there at present, I'll present it for xpert to rip apart. :-) > From: Benson I. Margulies <benson@odi.com> > I think that the root of my confusion is my failure to figure out how > the modifier keys work. [...] Is the server observing keypress for > Shift and then setting internal state that changes its interpretation > of "a"? Or is the binary code coming from the kernel for Shift-A > composed of the code for a orred in with a code for Shift? Neither. > Is there some client subroutine in Xlib that is conventionally called > that is really running the show? You got it. It's called XLookupString. A shift-A is simply a Keypress event for the A key with the Shift modifier bit set. CapsLock-A is another thing entirely. On keyboards with a mechanically-locking capslock key, lock is presumably handled by the server just like any other modifier key. On at least one other (the Sun I'm typing this on, for example), the X server notices key-down and key-up codes for the CapsLock key and "latches" it, making it appear to clients that the key locks down. (I agree this is a bad idea, but at present I have nothing better to propose.) XLookupString turns a keypress-for-A-with-shift-set into a capital A; keypress-for-A-with-capslock-set also becomes a capital A. On the other hand, keypress-for-5-with-shift-set becomes (say) a percent sign, whereas keypress-for-5-with-capslock-set becomes a normal 5. XLookupString is the routine that handles this. If you want different behavior - such as a NumLock key - then write your own version of XLookupString that does what you want. Test it out for a while. If you think it's good, tell xpert about it and if the X crowd agrees, it - or something like it - may make it into some future release. I agree that XLookupString could use a lot of work. For example, there is currently no way to arrange things so that a press on F4 gets turned into the string "foobar" (for example) uniformly. Xterm can handle this, but setting up a translation in xterm isn't much help when you're typing to a gnu-emacs window. Having to specify the same translation for each client is less than ideal, particularly when they aren't uniform in the way you specify it. (It's also not terribly convenient when you want to install the translation on the fly.) I'm mulling over ways of improving this, but haven't come up with anything that makes me happy yet. (When I do, I'll do as I recommended above - code it up, try it out, and maybe propose it to the community. Something like the way you have to call XRefreshKeyboardMapping on a MappingNotify event, perhaps something with special properties of the root window....) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
envbvs@epb2.lbl.gov (Brian V. Smith) (09/13/89)
In article <8909122249.AA22882@Larry.McRCIM.McGill.EDU>, mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) writes: < < < I agree that XLookupString could use a lot of work. For example, there < is currently no way to arrange things so that a press on F4 gets turned < into the string "foobar" (for example) uniformly. Xterm can handle < this, but setting up a translation in xterm isn't much help when you're < typing to a gnu-emacs window. Having to specify the same translation < for each client is less than ideal, particularly when they aren't < uniform in the way you specify it. This is precisely what is supposed to happen. The theory is that you want the F4 key (say) to send a different string depending on whether you are in xterm or gnu-emacs. _____________________________________ Brian V. Smith (bvsmith@lbl.gov) Lawrence Berkeley Laboratory I don't speak for LBL, these non-opinions are all mine.
benson@odi.com (Benson I. Margulies) (09/13/89)
This discussion seems to me to boil down to perhaps 2 questions. 1- Should there be a convention for a Num modifier. 2- where do lock keys come from. 1 has been answered in the sense that the consortium considers it a prima facia plausible idea and might act on it. I have a few comments on 2. The current Xlib/server permits me to define any old key to be a modifier key. Provision is only made for one modifier lock, though -- the one-and-only shift lock. except that lock isn't, from the point of view of lookupstring, a modifier lock. its just a modifier. It is distinct from Shift pretty much only in that it shifts less characters. So far, I'm just recapitulating my own education. However, most users expect to find a press-to-start,press-to-stop behavior from their shift lock keys. thus the sun server. Note, though, that the Sun server code isn't really Sun-specific. It's perfectly happy to turn any old key into a locking key. This suggests that locking (press to start, press to stop) modifiers are a generally useful feature. they are pretty essential to people with some handicaps, for example. So I find myself suggesting that just as I can xmodmap any old key to be Shift, I should further be able to specify that this mapping should have press-to-start/press-to-stop behavior. The conceptual problem here is that clients are free to ignore mappings, but its somew hat difficult to see how this feature could have the same property. -- Benson I. Margulies
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/14/89)
So I find myself suggesting that
just as I can xmodmap any old key to be Shift, I should further be
able to specify that this mapping should have
press-to-start/press-to-stop behavior.
It isn't really a property of the mapping, it's a property of the "key".
In the same way that you might want to control whether individual keys
do or don't toggle, I might want to control whether groups of keys
do or don't "radio-button". You can probably invent other behaviors
that you would like for keys or groups of keys. They are plausible
things to do, but they are outside the scope of the current X protocol,
and not all servers may want to heed your request, depending on what
their physical hardware limitations are. If you really want this,
you can go off and design and implement an X extension to do it, and
see if anyone is interested in the result.