Community Column: A House Built on Sand: 'To X or not to X' ReduxMar 25, 2001, 06:20 (33 Talkback[s])
(Other stories by David Wood)
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.