Path: utzoo!attcan!uunet!ginosko!usc!bloom-beacon!odi.COM!benson From: benson@odi.COM (Benson I. Margulies) Newsgroups: comp.windows.x Subject: Re: Inventing A Shift Key Message-ID: <8909121315.AA01197@cass.odi.com> Date: 12 Sep 89 13:15:27 GMT References: <8909112116.AA02930@devnull.sun.com> Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 36 The interpretation of keys is entirely up to the client. The Sun server is correctly reporting that: - There is a key marked "Num Lock" - When pressed, it goes down - When released, it comes up (i.e. it doesn't physically lock down) Thus, the clients find out what the actual state of the keyboard is. This is what the designers of the X protocol intended. How clients interpret this information is up to them. For example, if they decide to let down (or up) transitions of this key toggle their interpretation of other key events between a normal and a "Num Lock" interpretation, that is up to them. 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. David. 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? 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. 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.