Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!sgi!daisy!klee
From: klee@daisy.UUCP (Ken Lee)
Newsgroups: comp.windows.misc
Subject: Re: Why I'm suspicious of X
Message-ID: <849@daisy.UUCP>
Date: 17 Feb 88 23:07:37 GMT
References: <1684@desint.UUCP>
Reply-To: klee@daisy.UUCP (Ken Lee)
Organization: Daisy Systems Corp., Mountain View, Ca.
Lines: 45
Keywords: NeWS, X

In article <1684@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes:
>The biggest flaw with X, of course, is its baroque complexity.

I think X has a bigger problem than that, namely flexibility.  X takes
a very conservative approach to everything.  It works well, with
current hardware and current application programming styles, but really
doesn't look toward the future.  Some features that I think will soon
be important, but that are difficult or impossible to accomplish in X
are:

1.  input model.  Input has always been a weak point to graphics/window
systems.  X is no different.  Currently, the client must wade through
tons of low level events before it can construct a high level event to
act upon.  High level event handling is limited to packages like
menus.  A better input model would allow the client to specify how high
level input can be derived from low level events, then only worry about
the high level.  The object-oriented lightweight process mechanism in
NeWS makes this clean and easy.

2.  output model.  The X imaging model is very tightly tied to current
breeds of workstations (framebuffers, color maps, etc.).  NeWS, on the
other hand, uses a stencil/paint imaging model that can be used on a
much wider variety of display devices.  Both have their problems with
current applications, of course, but I think the NeWS model will be
applicable to a much wider class of future hardware.

3.  toolkits.  All the X toolkits that I've seen are function libraries
that must be linked to the client.  On the other hand, all the NeWS
toolkits (e.g., litewin, liteitem) are server extensions that you can
download (and modify) if you wish.  Implementing the toolkits in the
server saves memory, lowers communication bandwidth, etc.  It also
makes writing clients in languages other than C much easier.

4.  server programability.  This has been discussed on the net
already.  I still think it's a great idea.

5.  popularity.  This is both good and bad.  After only a year or so of
heavy use, X is becoming a defacto standard.  Can you imagine
standardizing on UNIX after so little time?  I don't have a solution
for this, but I would be suprised if X is still here 5 years from now.

Comments?  What do you think belongs in the window system of the
future?

Ken