home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / windows / x / 16138 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  6.3 KB
  1. Xref: sparky comp.windows.x:16138 comp.windows.x.apps:927
  2. Path: sparky!uunet!dtix!darwin.sura.net!wupost!usc!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!mouse
  3. From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
  4. Newsgroups: comp.windows.x,comp.windows.x.apps
  5. Subject: Re: Attention Earthlings -- Cross-Vendor X11 Server Mess!
  6. Message-ID: <1992Sep3.230804.16736@thunder.mcrcim.mcgill.edu>
  7. Date: 3 Sep 92 23:08:04 GMT
  8. References: <BZS.92Aug30043553@ussr.std.com>
  9. Organization: McGill Research Centre for Intelligent Machines
  10. Lines: 126
  11.  
  12. > Distribution: comp
  13.  
  14. Please don't misuse newsgroup hierarchy names as distribution lines.
  15.  
  16. In article <BZS.92Aug30043553@ussr.std.com>, bzs@ussr.std.com (Barry Shein) writes:
  17.  
  18. > The problem involves every different vendors' (server implementors')
  19. > idea of what goes into the Keysym tables.
  20.  
  21. > Basically, the tool to use to investigate this is "xmodmap -pk".  If
  22. > you run this on different platforms you will get wildly varying
  23. > results indicating wildly different understandings of what should be
  24. > there.
  25.  
  26. There's another problem: your failure to fully understand how X
  27. keyboard facilities work.  Yes, there are problems, but this isn't one
  28. of them.  Physical keys are numbered arbitrarily; these numbers are
  29. keycodes.  There is no "should" about what goes in the keyboard
  30. mapping, except that the ultimate mapping from physical keys to results
  31. when they're typed should bear some resemblance to what the user wants.
  32. The mapping "xmodmap -pk" prints is only one piece of this: the others
  33. are the mapping between physical keys and keycode numbers (can vary
  34. with keyboard manufacturer, operating system, X server, and probably
  35. other things) and the actions the applications in use take when they
  36. see keystrokes (beyond the scope of this discussion, mostly).
  37.  
  38. > The worst problems stem from a basic disagreement on whether the
  39. > keysym tables hold what the keycaps say (my understanding of the
  40. > spec) or everything the keyboard can generate.
  41.  
  42. Neither, quite.  The impression I get is that they would have liked to
  43. take the former approach, but bowed to pragmatism and (a) merged
  44. different names of identical function (eg, RETURN and ENTER), (b) split
  45. identical names of different function (eg, ENTER on main keypad and
  46. ENTER on numeric keypad).  (They also made some mistakes, like omitting
  47. some things altogether.)
  48.  
  49. > I don't know, consider a case like XK_equal (=) and XK_plus (+).
  50.  
  51. > Most keyboards have this on the same key, and all tables I checked
  52. > had both codes.  But this is only one key, the distinction being that
  53. > one glyph is shifted [...].
  54.  
  55. This is actually a very good point, which I hadn't noticed until you
  56. mentioned it.  The keyboard I'm using now has a key which is labeled as
  57. if it were "SPACE" unshifted and "BACK" shifted, but of course it's
  58. actually the backspace key.  Yet there's another key which *is* =
  59. unshifted and + shifted, and it's not a += key.  This is where
  60. pragmatism comes in: I don't expect a slavish adherence to labeling
  61. every key with precisely what's on top of it; I'd much prefer a looser
  62. approach that works better.  Which is what X does.
  63.  
  64. > But, for example, if as I understand the spec, that only one of XK_A
  65. > or XK_a (usually XK_A) should (usually) be in the table as some
  66. > vendors believe, how do I ever discover that there is another shifted
  67. > or unshifted keycode also generated by that key (typically the
  68. > unshifted is missing)?
  69.  
  70. Because of another botch (IMO): XLookupString is defined to be ISO
  71. Latin-1 dependent.  It *knows* which keysyms correspond to alphabetic
  72. characters that have both uppercase and lowercase forms.  (This is a
  73. pain when you want something else, like ISO Latin-5...I understand Xmu
  74. has some routines to help, though I've never looked for them myself.)
  75.  
  76. > Consider, as a practical example, the Keycaps DA on a Macintosh.
  77.  
  78. > How would you write it (portably) under these circumstances?
  79.  
  80. You can't, because as you point out there is no way to get the physical
  81. layout.
  82.  
  83. > (Forget the physical layout problem, that's beyond redemption in X11
  84. > right now, unless there's something I don't know about, amusingly OW3
  85. > puts the keysyms into the table in the order, right-left/top-bottom,
  86. > that they appear on the Sun Type-4 keyboard, but that's an exception
  87. > in my experience, would you rely on it?  I wouldn't.)
  88.  
  89. Then OW is doing some mapping.  The type-2 and type-3 keyboards
  90. generate keycodes that *are* in order like this, but the type-4 (and
  91. type-5, I assume) moved some keys but wanted to be keycode-compatible,
  92. so they aren't quite in order any longer.  Check carefully and I think
  93. you'll find a few keys that aren't in physical row-by-row order...
  94.  
  95. > Now, if you hold down Shift in this Keycaps thing the image changes
  96. > to display what the Shift of all the keys would send.
  97.  
  98. > And the same for their equivalent of Meta (Option or something like
  99. > that), and Control, and combinations.
  100.  
  101. > I don't believe that program can be written even barely portably in
  102. > X11 (and lo as far as I know nothing like it exists, nicht wahr?)
  103.  
  104. It can, for Shift and Caps_Lock/Shift_Lock, modulo physical layout
  105. assumptions.  Interpretation of Control and other modifier bits is
  106. sufficiently nonstandard (does that control-c mean interrupt, insert
  107. character 3, or what?) that the other modifiers can't be handled.
  108.  
  109. > So I would conclude that the spec is kind of broken [...]
  110.  
  111. I've never heard of anyone who would disagree with this....
  112.  
  113. > in that a correct implementation leads to a less than generally
  114. > useful result.
  115.  
  116. This doesn't always mean the spec needs work.  To pick another part of
  117. X, it would be perfectly legal to draw (zero-width) lines as
  118. axis-aligned rectangles of which the specified line is a diagonal.  Or
  119. as circles of which the line is a diameter.  But nobody actually does
  120. that.
  121.  
  122. > I personally think that XK_A and XK_a both in the table in a way that
  123. > they can be determined to be the shifted/unshifted versions of the
  124. > same key needs to be done or else there's just no way to query what
  125. > the keyboard can generate usefully.
  126.  
  127. The keyboard doesn't generate both a and A.  It generates events for
  128. the shift key and events for the A key.  It is the client's job,
  129. typically via XLookupString, to convert A-key-with-shift-down into an
  130. "A" character and A-key-with-shift-up into an "a" character.  If it
  131. wants to convert them to characters at all, that is; not all
  132. applications do.
  133.  
  134.                     der Mouse
  135.  
  136.                 mouse@larry.mcrcim.mcgill.edu
  137.