From: matt@centerline.com (Matt Landau)
Subject: Re: Attention Earthlings -- Cross-Vendor X11 Server Mess!
Organization: CenterLine Software, Inc.
Date: Mon, 31 Aug 1992 23:30:24 GMT

In <JWZ.92Aug31160057@thalidomide.lucid.com> Jamie Zawinski <jwz@lucid.com> writes:
>  -  There is no way to find out what is actually printed on the surfaces of
>     the keys.  I think you were saying that you think that there should be
>     a direct correspondence between the set of keysyms which a keycode 
>     generates and the text printed on the surface.  I don't think this is a
>     good idea.  They are two different pieces of information, one of which
>     you can change and one of which you can't.  (And, in the current system,
>     one of which you can interrogate and one of which you can't.)

The X11 protocol states explicitly that X11 keysyms use the so-called 
"Common" approach in which "similar" keys are grouped under a single 
Keysym, rather than the so-called "Engraving" approach, where every
unique engraving on every on different key on every different keyboard
in the whole world gets its own unique Keysym.

Actually, I think the intent was to have a model somewhere between
the Common and Engraving models, where the protocol would provide a
set of "standard" common keysyms, and vendors would augment it with
their own vendor-specific engraving-based keysyms for keys that have
no useful common representation.

We shall see momentarily where this decision leads...

>Of course, whatever monster intellect was responsible for the Xsun server
>decided that F15 was a really good name for the key which is physically
>labeled both "Front" and "L5", so this notion breaks down pretty quickly.
>It's not clear that this is a botch in the X standard, but it is most
>certainly a botch.

It's a combination of botches in the standard, in the Xsun server, and 
in the tools that are commonly provided for X11.  

The botch in the standard is basically that the "standard" set of common
keysyms doesn't include anything that looks like "L5" or "Front" as a 
unique Keysym (i.e., it neglected some of the keys on some of the most 
widely used keyboard in the industry).  Instead, the standard Keysyms 
*explicitly* make F11 and L1 aliases for each other, F12 and L2 aliases
for each other, etc.

But that's not the worst of it -- the standard set of common Keysyms also 
neglected to include Keysyms with names like "Cut", "Copy", and "Paste", 
which one might expect to be rather more common than "L5" or "Front".

The botch in the Xsun server is that, at least initially, it did not 
augment the standard set of Keysyms with "vendor private" Keysyms for
the Sun-specific key engravings.  One could argue that this is not a 
botch, since the "vendor" in question (the Consortium) didn't WANT to
get into the business of supported separate sets of keysyms for every
machine for which a sample server is distributed.

The botch in the application software is that most applications don't
know what to do with vendor-private Keysym defs even if they do exist.

In other words, the X11 keyboard representation model is kind of a mess.
But you already knew that :-)

>The part of the X spec which was no doubt involved in this pinheaded decision
>was the part that says that one should combine keys with similar intent: if
>one keyboard calls it "Enter" and another calls it "Return", then this should
>be transparent to the application.  That's fine for keys which are obviously
>congruent in intent, but calling the "R1" key "F21" was just an incredibly
>stupid idea.  I can't imagine why anyone thought this was a good idea.

Well, the limitations of the "Engraving" model are clear -- there is an
infinite number of possible Keysyms, which makes choosing a representation
and a standard set somewhat difficult.

On the other hand, mapping R1 to F21, and ignoring Cut, Copy, and Paste
was (in retrospect) pretty clearly a bad idea.
Newsgroups: comp.windows.x