NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/windows/x/16602

Internet Message Format | 1992-09-12 | 6.1 KB

Xref: sparky comp.windows.x:16602 comp.windows.x.apps:1020
Newsgroups: comp.windows.x,comp.windows.x.apps
Path: sparky!uunet!world!bzs
From: [e-mail] (Barry Shein)
Subject: Re: Attention Earthlings -- Cross-Vendor X11 Server Mess!
In-Reply-To: [e-mail]'s message of Tue, 8 Sep 92 22:02:44 GMT
Message-ID: <[e-mail]>
Sender: [e-mail] (Mr USENET himself)
Nntp-Posting-Host: ussr.std.com
Organization: The World
References: <[e-mail]> <[e-mail]>
    <[e-mail]>
Date: Sun, 13 Sep 1992 01:58:11 GMT
Lines: 114


From: [e-mail] (der Mouse) [responding to me]
>> It's not "do I get a reasonable response when I push this key", it's
>> "can I anticipate what I will get when keys are pressed".
>
>Unless the "I" is different, I don't see much difference.

To use an analogy, it's the difference between being able to do an
open() for a file you know exists in some directory versus being able
to ask for every file in a particular directory. You're saying all is
ok because you do an open("foo",...) and indeed foo opens. I'm saying
that I don't want to guess what files are available, I want to do an
opendir() and read off what files are here.

To continue, I claim although X11's "open" is fine I guess, if you do
an opendir() (i.e. try to figure out what keysym/keycode/modifiers
exist) it's indeterminate. And, in fact, different vendors'
"filesystems" will give you different answers for what seems to be the
same set of conditions.

Look, the problem is very simply demonstrated. Do an 'xmodmap -pk' on
several vendors' X servers around the office or whatever. Notice that
you get varying results for seemingly similar conditions (e.g. some
return XK_a and XK_A, others only have XK_A in the mappings).

Now, given that, try to imagine situations where that indeterminancy
might cause applications programming problems. Does the inconsistency
at least make you suspect that perhaps I have a point here that you're
missing? At least use your engineering sense of symmetry, even if the
underlying problem doesn't jump right out at you.

Again, back to the file analogy, imagine you used two vendors' unix's.

You read a directory that you knew was identical on each machine.

And you got back different results, in toto, a different number of
files. Say one returned both foo and FOO while the other returned only
foo.

So you point this out to the vendor, and the vendor says oh that's ok
because if you do an open("foo",...) it will do what you expect.

So you say yes, you know that open() works ok, but your ls command you
just wrote gives (necessarily) different output for the two different
systems.

Following what you're saying above, you're like the vendor and your
answer is ``why would you want to write an ls command? open works
fine'' or some such put off.

The difference is which direction the information flows: Enumerate the
set for me vs. tell me if some given item is in the set. I'm saying
you can discover that a particular item is in the set, but enumeration
is inconsistent from vendor to vendor.

>> If you're still having trouble with the distinction, imagine that
>> what your application is trying to do is set the XLookupString() for
>> all the possible keysyms (e.g. change the type-in font.)
>
>Hm?  Fonts are a display issue.  All the way from the keyboard through
>the returned values from XLookupString, fonts are completely
>irrelevant.  (I'm also not sure what you mean by "set the
>XLookupString()", especially since "all the possible keysyms" is an
>enormous number; even if you stick to the Consortium-standard ones in
>keysymdef.h, it's still a very large list.)

Indeed, but SOMEONE has to finally decide what glyph is displayed in
response to a keypress. SOMEONE has to map these onto each other. And
to map them together you (may) need a determinate list of what
keypresses can occur and even what they usually mean (i.e. their
KeySym) if you want to follow some heuristics for re-assignment.

Forget Latin-1, it's too easily mapped to the current standard and
that's one reason you are confused, it all maps rather easily onto
pre-conceived notions of ASCII collating (e.g. XK_a vs XK_A).

Imagine a character set where there is a strong convention that XK_FOO
is the shift of XK_GOO, but not in the upper/lower case sense (more in
the arbitrary but strong convention of = and + being shifts.)

Given the current use of the standard by vendors you may not be able
to discover (it's hit or miss) that XK_FOO is the shift of XK_GOO.
Only one of them may be in the keymap (e.g. what xmodmap -pk prints
out.) All you will know is that XK_GOO exists, and the shift key can
be pressed, perhaps that is XK_FOO? Maybe not.

You're too easily assuming that because a keymap tells you that XK_A
exists that obviously XK_a must be related to it by a shift. That is a
convention of Latin-1. But if you were trying to deal with, I dunno, A
Zapf Dingbats Keyboard from Zapfia it may not be so obvious that the
shift of XK_HAPPYFACE is XK_BULLSEYE. Yet, given current vendors'
standards, some seem to feel that both should be in the keymap, others
think only one of those (oddly, typically the SHIFTED version, not
really oddly because typically that's what shows on the keycap.)

All I'm saying is that each piece has its own sort of logic
(engravings, etc) but put it all together and it doesn't really spell
XK_MOTHER, and it's not even treated as a standard by vendors. And
perhaps the current "standard" is the confusion since although logical
it may not be useful, so many vendors go outside the standard to such
a point that an application can't be sure what it will find when
querying the keyboard.

You seem to want to keep explaining the way X11 works to me instead of
saying to yourself ``gee, maybe he really does understand the whole
mess and is making a point that doesn't make sense to me because it's
a bit subtle and I should think a little harder before assuming he
doesn't understand it?''

--
        -Barry Shein

Software Tool & Die    | [e-mail]          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD