Opinions expressed by contributors to Linux Today’s
‘Community Column’ are not necessarily those of LinuxToday’s staff
or management.
By David Wood
Okay,
my last column submitted to the Community Columns of LinuxToday
seems to have sparked quite a bit of dialog about the pros and cons
of X Window. After what some seem to think was a bold statement
about X being an antiquated system in desperate need of a major
overhaul, a great deal of hooplah ensued. Most of the early
talkbacks were folks disparaging my knowledge of X Window and its
subsequent client applications, window managers, etc.
Truth be told, I actually understand exactly what X is and is
not. I will not debate the endless semantics of whether or not a
function is the job of the X server, the window manager, the object
model environment, or the client application. All of the issues I
mentioned are a direct result of a GUI model that is woefully
inadequate for today’s needs. Below is what I believe is a workable
plan for solving the problem. Beware you programmers out there: it
is intentionally straightforward so as not to confuse the “lusers”
you disdain so much.
One of my readers made an excellent analogy between X and
Pre-Copernican Astronomy. It has become clear that a new model must
appear. It’s time for a new specification. To determine a clear
course of action, we must identify the shortcomings of the old
system(i.e. X) and determine what can be used in the new system and
what cannot. XFree86 does not need to go away. Rather, it should
become an application in much the same way that it is under MacOS
or Windows. This would allow us to continue to use X applications
without foregoing the benefits of a new windowing system. Below is
a rather incomplete roadmap of what a new windowing system might
consist of.
The XFree86 display drivers that are becoming rather extensive
should be converted to Linux kernel modules and submitted to Linus
for approval and incorporation into the tree. If you don’t like
them, you can always not load them and stick with “ye olde 80
column VT.” The benefit to doing this is allowing the new windowing
system to be hardware independent. In much the same way that an
application can write to any recognized file system regardless of
the controller by a few simple function calls. What we must be most
careful of is providing a way to prevent errant function calls from
crashing the kernel, a common problem with MS Windows.
Next, we need a basic windowed application API written in C.
This provides a layer of abstraction between the video driver and
the running applications. This API should provide basic functions
for drawing building windows, menus, dialogs, etc. As in any event
driven system, the API must be built around a running app that
traps and sends to client apps the various events. The API should
include a library for entering, editing and deleting mime types
from the system in a common “user specific” location (i.e.
.desktop/mime.types.db). The clipboard should support object
embedding. There are plenty of CORBA implmentations to use.
Finally, the API should incorporate the functions already built
with SDL. Wanna head this up Sam?
Okay, now we have a working idea. I’ll start a Sourceforge
project if anyone sends me any interest. Many thanks to ALL of the
talkbacks for giving me advice, no matter how obnoxious or
arrogant, on how to clarify my intentions. Every reader at
LinuxToday does make a difference.
Interested in submitting a Community column for publication on
Linux Today? Contact the
editors with a brief summary of what you’d like to write about.
Not all proposals will be accepted, and we do reserve the right to
edit submissions.