Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!sco!mikep From: mikep@sco.COM (Mike Patnode) Newsgroups: comp.windows.x Subject: Re: PC/AT Keyboard X Keysym Proposal - R.F.C. Keywords: Some F. Comments; Use Num Lock Message-ID: <9510@scolex.sco.COM> Date: 9 Jan 91 22:58:11 GMT References: <1607@pai.UUCP> Sender: news@sco.COM Organization: The Santa Cruz Operation, Inc. Lines: 146 X i386 Developer's BOF note: The BOF will still be held Tuesday night but will be scheduled to not conflict with the X Security BOF. Hopefully it will immediatly follow the Security BOFF in the same room. Please check the Notes Board at the conference for details. In article <1607@pai.UUCP> erc@pai.UUCP (Eric F. Johnson) writes: >Regarding PC Keyboard Keysyms: > Much more deleted as I get to the meat and potatoes of Eric's reasoning. > > The X Keysym definition provides special keysyms for > most keypad keys which may also be present elsewhere on the > keyboard. > >I don't like those either, but if you've ever used VMS applications, >you'll see some rational for making the keypad keysyms separate. (I >still think a "1" is a "1" is a "1", to paraphrase Gertrude Stein.) What about XK_Alt_L and XK_Alt_R? XK_Enter and XK_KP_Enter? >Argh. This will also make coding for multiple (e.g., PC and NON-PC) >systems FUBAR. One of the major benefits of X is portability. >With your proposal, we'd all have to add special-case code for >PC-based systems. Why special-case code? If you did not want to differentiate the two arrow keys your code, but you wanted to run on a PC you would change: case XK_Up: foo(); to case XK_Up: case XK_KP_Up: foo(); No special case needed. > > This introduction of new keysyms may cause some problems > with existing applications, but it is hoped that most X > programs should be able to overcome these incompatibilities > via the translation table mechanism. > >Give me a break. (If you require every X user to learn the translation table >mechanism, you're severely limiting the potential number of X users.) I concede this point. Another solution is to use xmodmap. Backwards compatibility is not a strong point of this proposal. > 3. New Keysyms > > Finally, there is no > Page Up or Page Down keysym defined. > >Yech-o. Use XK_Prior and XK_Next. It's a toss up in my mind. Prior and Next definitely would be better existing applications. > The PC/AT Keyboard does not have a unshifted glyph on the > center keypad key (numeric 5). For the sake of consistency > the existing KP_Space keysym should be used here. > >Why not use XK_VoidSymbol, since the keypad 5 in page control mode >does nothing on DOS machines anyway? Inserting a space char may confuse >users. You're probably right here. The more I think about it, the space is sort of silly. > >Mike, in my X applications, the concept of the Caps Lock key is essentially >transparent. That is, when the Caps Lock is in the active state, my >applications see "A" rather than "a" (or XK_A rather than XK_a). This >means that my code doesn't have to program special cases for the Caps Lock >key. This makes my job easier than it would have to be otherwise. Now, why can't >the Num Lock key work much the same way? In other words, why can't your >proposal make the Num Lock function essentially transparent to my application, >e.g., through XLookupString() and the associated functions? > I absolutely believe the Num_Lock key should act just like the Caps Lock key. One thing that should be done is the Num_Lock should be given a standard spot in the modifier table. This is yet another problem which everyone is solving differently. Sigh. >If my code sees an XK_Up, it will know that an Up Arrow key was pressed, >whether my code is running on an X terminal, a non-PC workstation or >a PC-based workstation? If my code sees XK_Insert, it will know the >Insert key was hit (except for an HP, but that's another matter). Millions of >DOS users seem to handle the Num Lock concept just fine. Why not use >that for PC-based UNIX systems as well? (An added benefit is that this >will make it easier for DOS users to migrate to UNIX, and I suspect that >a large number of SCO customers are migrating from DOS to UNIX, so you >want to encourage this.) Yes, and a large number of DOS Developers are migrating to UNIX as well and the one question I keep on seeing over and over again is: "How do I tell the difference between the regular arrow key and the keypad arrow key?" The philosophy is that every Keytop (engraving) on the keyboard should have a unique X Keysym associated with it. This is why there is a XK_Shift_L as well as a XK_Shift_R. >Please don't take this personally. Not at all. Thank you for your comments. >It just seems that using >the Num Lock key the way it was designed (for better or worse) is >a LOT easier than adding in new arrow keys when we already have arrow >keys. I think if you go back and look at Appendix E of the Red (Purple?) book you'll see why I decided to try to add some new Keysyms. I strongly believe that every key on the keyboard should have a unique identifier. If we only use the Num_Lock key, then it becomes almost impossible to differentiate between the keys unless you look at the Keycodes. Then you have an even more system specific case. In the long run, new Keysyms will provide a more consistent solution. mp ------ Mike Patnode The Santa Cruz Operation Software Engineer 400 Encinal Street {ucscc,uunet}!sco!mikep mikep@sco.COM P.O. Box 1900 (408) 458-1422 Santa Cruz, CA 95061 -- Mike Patnode The Santa Cruz Operation Software Engineer 400 Encinal Street {ucscc,uunet}!sco!mikep mikep@sco.COM P.O. Box 1900 (408) 458-1422 Santa Cruz, CA 95061