Path: utzoo!utgpu!water!watmath!clyde!bellcore!decvax!ucbvax!hplabs!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: comp.windows.misc
Subject: Why I'm suspicious of X
Message-ID: <1684@desint.UUCP>
Date: 17 Feb 88 07:06:15 GMT
Reply-To: geoff@desint.UUCP (Geoff Kuenning)
Organization: Interrupt Technology Corp., Manhattan Beach, CA
Lines: 56

Well, my posting criticizing NeWS certainly achieved its goal of
provoking discussion!

To give the other side a fair chance, I thought I'd stir things up a
bit more by pointing out some major flaws in X11.  (Equal time and
all that, you know -- it's primary season here in the U.S. :-)

The biggest flaw with X, of course, is its baroque complexity.  Need
to draw a rectangle?  No problem, X has four or five different ways.
There are two major ways to paint text, each supported by several
library routines that have essentially the same argument lists.  I
confess I can never remember whether I want to "Draw" or "Image"
a string.  This goes on and on, until there are over 100 routines in
Xlib.  It's so bad that somebody recently complained about the
alphabetical arrangement of the recently-published Xlib manual;  while
it's easy to find the description of a known routine, one badly needs a
categorized listing to discover how to (e.g.) discover the
characteristics of the current visual.  (To be fair, X11 is vastly
better than X10.)

Contrast this with Postscript and NeWS, which manage to compose a
(relatively) small number of operators to get a lot of operations.
Whether you want a rectangle, circle, or character, you build it with a
"path" and then decide whether you want to stroke (that always sounded
obscene to me :-) or fill it.

Another problem with X, to my eyes, is that the X consortium has
allowed those of us on the outside to force them into rushing the
release.  (Not to criticize the individuals involved -- we all know
what pressure can be like!)  The result is several areas that are still
too "researchy" and ill-defined.  For example, when I first asked about
the interaction of colormaps with window managers, the basic response was
"Well, we really haven't had time to play with that much.  Any suggestions?"
I have yet to raise the issue of colormaps and colored cursors, but it's
pretty obvious there are serious problems.

A final defect is a pretty obvious "Not Invented Here" syndrome.  For
X11, they picked up the Postscript ideas on line cap and join styles.
But it would appear that they did this on hearsay, rather than actually
reading the Postscript manual, because some very simple and effective
ideas from Postscript were *not* picked up.  Postscript has a way to
limit mitering on narrow-angle joins, to prevent huge spikes.  X11 has
none.  Similarly, Postscript has a way to specify the approximate
accuracy of curve and arc rendering, so you can trade off speed and
esthetics.  Not so for X11.  Try drawing a 5x5 circle of linewidth 2
on the X11 sample server -- you get a pentagon.  Obviously a server
implementer can change this and produce an octagon or whatever, but the
applications programmer has absolutely no control, and the protocol can't
talk about it without an extension.

At this point, a lot of this is moot.  The NeWS/X war is going to be won
in the marketplace, not on the technical front.  I think I see a lead for
X, because the variety of companies that support it is larger.  It will
be fun to see if the marketing wizards at Sun can overcome this lead.
-- 
	Geoff Kuenning   geoff@ITcorp.com   {uunet,trwrb}!desint!geoff