X sucketh most verily? (was: Re: X->XX->X problem)

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Josh" == Josh Glover <jmglov@example.com> writes:

    Josh> X, as a windowing system, seems to have some problems. Some
    Josh> of the ones that I am aware of are:

Everything has problems.  The question is what do the solutions cost?

    Josh> 1) The programming interfaces are somewhat (or very,
    Josh> depending on whom you ask) shitty.

Um, yes.  It's an object-oriented API written in a language whose
express purpose is to avoid object orientation.  Life is like that.
"How about a Qt display?" and "Why not write [X]Emacs in C++?" are
perennial questions on the [X]Emacs channels.  The answers are "not
this decade"[1] and "because 'standard C++' is an oxymoron, and C++ is
too picky to _not_ be standard".  There's more to the world than
Linux, and even in Linux you can't bet your windowing system on the
C[++] compilers (cf. Red Hat's "the best GCC" which is rumored to be
"uh, deprecated is the polite way to put it" by the GCC team[2]).

And Qt itself gives the lie to the interface question; you just write
a better interface.  (Not to mention the Lisp machines.  "Long live
the Lisp machine!")  The X protocol, and Xlib and Xt themselves, allow
that.  That's hard to beat in real time with a "from scratch" design.
If real object-oriented interfaces were The Answer, Qt/KDE would have
overrun the competition long ago.  (Unfree license or not.)  They're
not close.

    Josh> 2) It seems that X is functioning in many ways for which it
    Josh> was never designed. In short, it is a collection of clever
    Josh> hacks, hacks, and kludges.

That's what we get for dumpster diving.  For heaven's sake, the X11 we
use on Linux today is what the corporate members of the X Consortium
considered too primitive to be worth making proprietary!

But my experience with X programming has mostly been that, in terms of
today's technology, too many of the sanity checks are left up to the
user.  Mostly what I've seen of the internals hasn't been particularly
clever or hackish.  (But I don't mess with the multiplexing.)  The
stuff (process control, signals, threading) that X gets "wrong" often
seem to be far more an issue of OS brokkedness than an X problem (and
I'll note that Windows API doesn't seem to get it much better, at
least from the point of view of an app like Emacs---despite the
advantage of having only a single local display to worry about, ever).

If you're talking about Uvator's problem (and similar), note that you
simply couldn't even try to fsck up that way on Windows.  Windows (the
only Windows) owns the screen.  Go away, hijacking earns the death
penalty.  The general screwage in X startup (X, xinit, xdm, startx,
xsm, window managers, GNOME, etc, etc)?  Well, I dunno.  Maybe we
should emulate Windows and have a standard init for the masses, and
only gurus can customize.  Funny thing, though, nobody seems to be able
to agree on what the standard should be, although most of the masses
seem to be pretty satisfied with the GNOME or KDE desktops.  But even
those are far more customizable in important ways than Windows.  So I
don't think that's a matter of design.

    Josh> 3) It leaks memory to a degree ranging from not so bad to
    Josh> downright Windows-esque.

I haven't noticed this.  My X server runs for weeks at a time and tops
out at about 70MB.  Considering that that includes several Japanese
fonts, I run with backing store enabled on a 1600x1200 display, etc,
etc, and that these days a graphics card with 32MB is considered
"minimum", I don't think that's an absurdly large footprint.  It
doesn't get much bigger than that; that's not a leak.  Sure it would
be nice to reduce it, but it doesn't take my machine down the way
HotJava and other Java apps used to do.

If you want something _small_, that's another issue.  Remember, the
whole point of X is that the machine running the app is free of the
overhead of the window system (if you want and can afford it).  But
small probably could be done (with an extension).

    Josh> there may be room in the Open Source world for another
    Josh> windowing system, of a better design.

As Jonathan mentioned, there's the Berlin project.  It hasn't gone
anywhere in a decade or so.  I don't think it's likely to do so.  The
X protocol itself is a mature, mostly satisfactory technology.  Its
Xlib (C language) binding is a reasonable foundation for toolkits (Xt,
Qt, GTK+, DPS, etc).  The API problem, as far as I can tell, comes
down to the difficulty of creating a good general toolkit.  All the
general-purpose toolkits suck pretty badly in their own ways.  And
most of the design problems with the X protocol can be solved
satisfactorily through the extension mechanism.

The servers seem to work on most cards.  They could be somewhat
faster, multithreaded, and smaller, but it's not clear to me that a
better design would achieve that within a decade.  The problems
"addressed" by being slow, single-threaded, and large are real, as far
as I can tell from the comments that people who do know about this
stuff deeply make.  They'll require a lot of effort to deal with, even
with the better design methods available almost 20 years after the X
protocol was finalized.

The main question is should we be using a networked window system, or
should we assume that every machine is a workstation that runs the
apps as well?  I happen to have a lot of resources; I'm pleased with
the network window system design.  But we could certainly save a lot
of resources and complexity by throwing out that design.  In the long
run....

The X font system does have problems.  But these (at long last) are
being addressed.  Agreed, you need to be able to throw resources at
them (eg, the large font loading delay is "fixed" by having long-lived
font servers taking up lots of memory so that you only load a font
once every few months).  But this could probably also be fixed with
extensions (cf TeX's tfm files and Adobe's afms).

The X Toolkit (Xt) and the Athena Widgets are definitely neolithic.
That's why we have GTK+, Qt, and so on.  But Xt still is the
industrial strength technology, it is still the common denominator.

The biggest problem with another windowing system, though, is the GUI
problem in spades.  Why do all of Motif, GTK+, Xt/Athena, and Qt suck?
Because they all have their adherents, and they can't share code very
much.  So improvements to any have to be copied in all before they get
propagated to all apps.  If you develop a new windowing system from
the ground up, you'll either have to enforce the toolkit level, thus
taking longer to making everybody happy, or permit multiple toolkits.
Haven't we made that mistake often enough?

X has its problems.  But you'll have to _show me_ what the likely
benefits are of a new windowing system, and that they outweigh the
probable costs of dividing our attention between a mature technology
with problems, and an immature technology without features (currently
implemented).


Footnotes: 
[1]  Not true any longer.  But it's still probably several years away.

[2]  According to Robert Pluim on xemacs-beta.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."