From: bzs@ussr.std.com (Barry Shein)
Newsgroups: fj.mail-lists.x-window
Subject: Attention Earthlings -- Cross-Vendor X11 Server Mess!
Date: 30 Aug 92 10:26:02 GMT
Distribution: fj
Organization: The World

Date: Sun, 30 Aug 1992 09:35:53 GMT
Message-Id: <BZS.92Aug30043553@ussr.std.com>
Newsgroups: comp.windows.x,comp.windows.x.apps


Ok, I've spent several hours investigating this on several platforms
and I've concluded something is seriously, seriously hosed out here on
Planet X11.

The problem involves every different vendors' (server implementors')
idea of what goes into the Keysym tables.

Basically, the tool to use to investigate this is "xmodmap -pk". If
you run this on different platforms you will get wildly varying
results indicating wildly different understandings of what should be
there.

The worst problems stem from a basic disagreement on whether the
keysym tables hold what the keycaps say (my understanding of the spec)
or everything the keyboard can generate.

For example, XK_a and XK_A (and other alphabetics.)

My understanding of the spec says it's almost always wrong to have
both of these in your keysym table because most likely the key only
displays one of these (typically, XK_A).

And in fact some vendors (e.g. NCD) do exactly this.

Most others have both codes, XK_A/XK_a (e.g. Openwindows-3, AIX 3.1
X11R3, X11R5 on a Sparcstation, NCR, etc.)

HOWEVER, which is right in some larger sense?

I don't know, consider a case like XK_equal (=) and XK_plus (+).

Most keyboards have this on the same key, and all tables I checked had
both codes. But this is only one key, the distinction being that one
glyph is shifted (and that's what XLookupString() believes also, I
REALIZE THIS IS ALL MUTABLE, but that's not important here, heck, I
can rewrite X11 if I really want...what's important is what
applications can expect when they run and query a server.)

But, for example, if as I understand the spec, that only one of XK_A
or XK_a (usually XK_A) should (usually) be in the table as some
vendors believe, how do I ever discover that there is another shifted
or unshifted keycode also generated by that key (typically the
unshifted is missing)?

Consider, as a practical example, the Keycaps DA on a Macintosh.

How would you write it (portably) under these circumstances?

(Forget the physical layout problem, that's beyond redemption in X11
right now, unless there's something I don't know about, amusingly OW3
puts the keysyms into the table in the order, right-left/top-bottom,
that they appear on the Sun Type-4 keyboard, but that's an exception
in my experience, would you rely on it? I wouldn't.)

The Keycaps DA is this little doo-dad which pops up a keyboard on the
screen and shows you what each key would send if pressed (and pressing
a key inverts the key image), in a specific font (imagine that, they
thought a bit about typing in other fonts! Ah well.)

Now, if you hold down Shift in this Keycaps thing the image changes to
display what the Shift of all the keys would send.

And the same for their equivalent of Meta (Option or something like
that), and Control, and combinations.

I don't believe that program can be written even barely portably in
X11 (and lo as far as I know nothing like it exists, nicht wahr?)

Yet it would seem there was some intention that something like this
could be written.

So I would conclude that the spec is kind of broken in that a correct
implementation leads to a less than generally useful result.

And worse, vendors who vary from the strict interpretation vary in all
sorts of strange ways once left to their own, er, devices.

As an example, Openwindows-3 seems to claim it has an F16 key which it
clearly does not (although they may be referring to something on the
keypad or something, there's reason to it, just not disciplined
reason, there are other oddities in there as well, but I'm not picking
on Sun, it's just weird out there.)

SO...A SUGGESTION TO THE X11 GROUP:

1. Clearly define how servers should implement this aspect of a
server, try to lay out typical wrong and right implementations. The
X11 books I have here (including RWS's X11R4) are vague at best and
even contain some errors which lead to more frustration trying to
understand this tho not directly, one just quickly loses faith that
this was thought about carefully (I'm not flaming the book, it's a
great book, but the vagaries in this area come thru.)

2. Educate vendors on this point, maybe put something in the FAQ and
top-level of the X11 server source tree.

3. First consider changing the spec to fit what applications
developers really need.

I personally think that XK_A and XK_a both in the table in a way that
they can be determined to be the shifted/unshifted versions of the
same key needs to be done or else there's just no way to query what
the keyboard can generate usefully. This is in spite of the fact that
I do understand that that goes against the original philosophy of this
part of the spec, I think that original idea was flawed (if I
understand it correctly, and I think I do.)

Thank you for your time.

PS NOTE: This can probably be fixed for now with a program run off a
table of what should be in there for each vendor/keyboard, run at
xinit, right? Even across various X11 releases. But it has to get wide
usage for applications developers to be able to rely on it.

--
        -Barry Shein

Software Tool & Die    | bzs@world.std.com          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD