Path: utzoo!attcan!uunet!ginosko!usc!bloom-beacon!SUN.COM!dshr
From: dshr@SUN.COM (David Rosenthal)
Newsgroups: comp.windows.x
Subject: Re: Inventing A Shift Key
Message-ID: <8909121622.AA03377@devnull.sun.com>
Date: 12 Sep 89 16:14:38 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 33

> So you would put code into every single client to individually 
> interpret Num Lock? Doesen't that leave something to be desired in terms
> of modularity? 
> 
The goal is not modularity (though for any system that supports
shared libraries,  there cost is insignificant).  The goal is
flexibility.  The goal is to allow clients that deal with the keyboard
in different ways (for example,  Japanese and Spanish) to co-exist.  Or
for a single client to be able to deal with the keyboard as required for
Korean and Urdu.

> 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.
> Surely, then, one would want the server to simulate it. Or would you prefer
> each client to independently invent shift lock just in case some workstations
> didn't maintain state in the hardware or kernel.
> 
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.

> The standard keysym inventory includes the KP keysyms, just as it
> includes both "a" and "A". 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. So I suggest that the standard
> interpretation of NumLock should be to shift into the KP symbols.
> 
You clearly don't understand the first thing about how keyboard support
works in X,  or you would not have made this suggestion.  Please study
pages 352-353 and 506-509 of the Digital Press book before continuing
this conversation.

	David.