Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!think!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: NumLock and similar keys
Message-ID: <8909122249.AA22882@Larry.McRCIM.McGill.EDU>
Date: 12 Sep 89 22:49:08 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 79

> 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