home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / windows / x / 16021 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  3.0 KB
  1. Xref: sparky comp.windows.x:16021 comp.windows.x.apps:906
  2. Newsgroups: comp.windows.x,comp.windows.x.apps
  3. Path: sparky!uunet!world!bzs
  4. From: bzs@ussr.std.com (Barry Shein)
  5. Subject: Re: Attention Earthlings -- Cross-Vendor X11 Server Mess!
  6. In-Reply-To: Jamie Zawinski's message of Mon, 31 Aug 92 23:01:06 GMT
  7. Message-ID: <BZS.92Sep1230158@ussr.std.com>
  8. Sender: usenet@world.std.com (Mr USENET himself)
  9. Nntp-Posting-Host: ussr.std.com
  10. Organization: The World
  11. References: <BZS.92Aug30043553@ussr.std.com> <JWZ.92Aug31160057@thalidomide.lucid.com>
  12. Date: Wed, 2 Sep 1992 04:01:58 GMT
  13. Lines: 56
  14.  
  15.  
  16. From: Jamie Zawinski <jwz@lucid.com>
  17. >  -  There is no way to find out what is actually printed on the surfaces of
  18. >     the keys.  I think you were saying that you think that there should be
  19. >     a direct correspondence between the set of keysyms which a keycode 
  20. >     generates and the text printed on the surface.  I don't think this is a
  21. >     good idea.  They are two different pieces of information, one of which
  22. >     you can change and one of which you can't.  (And, in the current system,
  23. >     one of which you can interrogate and one of which you can't.)
  24.  
  25. From private and on-line conversations with X devpt people going back
  26. to the original design of X11 I am 99.9% sure this was exactly the
  27. motivation for the keysym table entries.
  28.  
  29. Actually, from "X Window System", Scheifler & Gettys (et al), 1990, p
  30. 376:
  31.  
  32.     A KEYSYM is an encoding of a symbol on the cap of a key.
  33.  
  34. >if
  35. >one keyboard calls it "Enter" and another calls it "Return", then this should
  36. >be transparent to the application.
  37.  
  38. Oh, I don't know, the application might choose to call them the same
  39. thing, but as we reach for a lower and lower level of user it might be
  40. useful to be able to prompt with exactly what is on the key we want
  41. ("Type ENTER to continue" vs "Type RETURN to continue".)
  42.  
  43. We all remember the possibly apocryphal tale of the person who, when
  44. confronted with "Press ANY key to continue" went looking for someone
  45. to tell him where the damn ANY key was?
  46.  
  47. (I just grabbed and built and ran xkeycaps while typing, very cute, I
  48. like it! I think the code will also be useful.)
  49.  
  50. >Basically, the whole X keyboard model is a complete mess.  It is as good as
  51. >no standard at all, because to get anything done, you need to have hardware-
  52. >and vendor-specific knowledge anyway.
  53.  
  54. I think we're in violent agreement.
  55.  
  56. What are your thoughts on the possibility of writing a program which
  57. can be run at X server startup which maps all the keys to a standard
  58. (i.e. a description file is supplied for each keyboard, analogous to
  59. what you've done in xkeycaps), and I suppose a standard resource or
  60. Atom can be provided which identifies the keyboard as a string?
  61.  
  62. My current guess is that something like this can be thrown in and
  63. thrown at server vendors without any change to any existing code, no?
  64.  
  65.  
  66. --
  67.         -Barry Shein
  68.  
  69. Software Tool & Die    | bzs@world.std.com          | uunet!world!bzs
  70. Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
  71.