Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!SUN.COM!dshr From: dshr@SUN.COM (David Rosenthal) Newsgroups: comp.windows.x Subject: Re: Sun Type 4 Keyboad and X Message-ID: <8906091925.AA00726@devnull.sun.com> Date: 9 Jun 89 19:08:36 GMT Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 33 > This would have to be done in xterm. The problem is that the num_lock key > is defined as a function key, not as a modifier. (RWS - If you are out there, > WHY?). This comment reveals a lack of understanding of the way keys and modifiers are handled in X11. There is no such thing as a defined modifier key in X. There are 8 modifier bits (NOT keys). The Shift, Lock, and Control bits (NOT keys) are predefined. The other bits can be assigned as required (for example, to a NumLock modifier). The mechanism for doing this is described in the ICCCM. Note that the things that affect modifier bits are keycodes, not keysyms. There is no practical sense in which any keysym (such as num_lock) is defined as a function keysym, or a modifier keysym, or as any different from any other keysym. Keysyms simply describe the symbol(s) on the keys. They are simply hints that a client may use to attach meaning to a keycode or may ignore at its pleasure. Any number of keys can be defined to affect the state of a modifier bit - the set of keys that affect each bit is dynamic. Modifier bits are a scare resource in X11, which is why the ICCCM describes mechanisms for assigning them dynamically as required. It is also why only a small number of the possible modifiers are pre-assigned - I argued against pre-assigning Lock as well. Your comment about xterm is an example of the general problem. The mapping of the key events to (for example) ASCII digits is a matter for each individual client. Uniform support for a NumLock modifier across all clients involves changing the Xib implementation they all use. Simple enough for a single machine (if you have shared libraries) but not so easy if some of your clients are elsewhere......... David.