Why the X server should be an "ex-" server!
By MoxFulder in Technology
Thu Nov 02, 2000 at 06:23:25 AM EST
Tags: Software (all tags)
First off, I'd like to applaud the developers of both KDE and Gnome.
They've done an admirable job of increasing the usefulness of Linux as
a desktop OS, with standard and user-friendly interface design, suites
of useful and standardized applications, graphical configuration, and
But nagging details still hold both desktop environments back. Who
hasn't tried to get a wheely-mouse to work by clicking on Gnome
Control Center, only to find that Gnome has its hands tied by the
underlying X server? And who has ever copied an image from Gimp to the
clipboard and back, without a complimentary mangling courtesy of the X
The X Window System is the silent partner in all Linux desktop
environments to date. By itself, X is rather harmless, mostly because
it doesn't do all that much. An X server isn't much more than a
glorified raster graphics library like SVGALib, providing routines to
plot pixels and requisition rectangular windows of the screen. Oh,
and let's not forget that it allows mouse and keyboard input :-)
As is pointed out in The
X-Windows Disaster, X provides a graphics mechanism but
hardly any user-interface policy. That's why there are so
many "standard" interface toolkits, "standard" keybindings, "standard"
drag and drop and clipboard protocols, etc. Have you ever used
"xedit"? Try running it and then you'll see the beautiful X
user-interface in all its glory! No wonder the Motif, Tk, Gnome,
and KDE toolkits were invented!
KDE and Gnome are the latest and greatest user-interface policy layers
superimposed on the X Window System. Both do a good job of providing a
standardized interface, and they are fast improving. But they are
still at the mercy of the underlying X server! Too often, Gnome or
KDE are rendered helpless by the surly X server, which must be tamed
through the XF86Config file, whose friendly looking file format has
lured in many a newbie.
Additionally, X is a memory hog ... I'm not sure why it is using 47
megs of memory on my system at the moment, considering that Gnome is doing most of
the hard work, but I don't really care either. X is inefficient and
wasteful, needlessly bogging down the elegant desktop environment
running on top of it.
Since I don't want this to be a rant, I'd like to point out
my favorite feature of X: its network transparency! With just three
commands, "xhost", "telnet", and "DISPLAY=", I can display a program
running on the computer at work on my screen at home! Handy, that!
Unfortunately, in network transparency as in all things, the X server
implements the lowest common denominator in terms of policy: it transmits
all graphics commands and input events directly across the
network, making the protocol ridiculously slow for any truly graphical
To make a long story short, X has one good feature and a laundry list
of annoyances, inefficiencies, and inconsistencies. To deal with
these, the designers of Gnome (as an example) had to write several
layers of glue libraries to keep the X server at a safe distance from
user applications. Compare the Gnome program-to-hardware interface
with the MS Windows application-to-hardware interface:
- Kernel Device Drivers -- Handle keyboard and mouse input.
- X server -- Handles graphical screen output and obfuscates keyboard and
- Xlib -- A horrendously complex library for basic windowed graphics,
- Gimp Drawing Kit -- Quarantines
the atrocious Xlib within a wrapper library.
- Gimp ToolKit -- Provides
a set of widgets, or user interface elements, like text boxes,
buttons, scrollbars, etc.
- Gnome -- Provides internationalization, audio support, the Gnome
panel, standard keybindings, standard icons, etc.
MS Windows (last time I checked):
The Windows paradigm is considerably more streamlined. Now, I'm not saying that we should all be using Windows (anything but
that!) In fact, the USER.EXE library is quite bloated under current
versions of Windows. What I'd like to see is Linux desktop
environments freed once and for all from the constraining X
Window System. Here are my proposals for streamlining graphical user
environments under Linux:
- Device Drivers -- Handle keyboard and mouse input and graphical
- Graphical Device Inteface -- Provides basic
windowed graphics and drawing routines.
- USER.EXE -- Provides windowing, widgets, audio, etc.
If we do all these things, Gnome and KDE, as well as Linux itself,
should improve immensely, to the point where they are far, far better than any other desktop OS!
- Graphical console drivers should be handled in the kernel!
The Linux kernel is compiled with support for the standard text
console, why should it not include support for a standard raster
graphics console as well? Of course, there are many different types
of graphics cards with different command sets, so each system would
only use the ones it needed, as loadable kernel modules. Each could
export a set of standard entry points that would make it device
independent, just as the text console is (mostly) independent of the
underlying graphics hardware.
- Create standard (really!) libraries for clipboards, drag-and-drop,
internationalization, audio, etc. These could be used by text
applications as well as graphical ones, of course!
- Create a better mechanism for network transparency in which the user interface (written in Java perhaps?), can be run on one computer, while the code that does the work executes on another.
- Build graphical desktop environments on top of these!
Finally, let me provide some compelling
evidence that graphical user interface shortcomings are to blame for Linux's lukewarm reception as a desktop OS thus far: Recently, a friend of mine got Mac OS X Beta.
It's undoubtedly the best Mac OS ever, and it's based on a Unix BSD core, with
a graphical desktop environment on top. The catch? The graphical
environment, Aqua, is not based on X Windows, unlike nearly
every other Unix graphical environment. No, it is a proprietary
environment developed by Apple. Undoubtedly, Mac OS X will be a great
user OS because of its intuitive and seamless graphical environment.
But it won't be as dumbed down as Windows or old Mac OS's because,
under the pretty pictures, there's a shell, a unix filesystem hierarchy,
and text-based configuration files.
Apple was able to break free of the inertia that bound its elegant graphical environment to weak memory management, networking, and filesystem code. Can Linux developers similarly separate our elegant OS from our obsolete and inefficient graphics model? If so, it will be a great day for Linux and for the graphical desktop!