Jim Gettys, Copyright 1998, All Rights Reserved - distributed by Freshmeat with permission of the author.
I lost track of X Window System during the last few years, in spite of my intimate involvement with its original development. My interests had moved from X, to audio work for a while, and then on to the Web.
For my recent work I needed business productivity tools (e.g. Microsoft Word, PowerPoint, etc.) much more than a programmer's system. While X had fine engineering software available, such routine tools as WYSIWYG editors or presentation programs were not available at reasonable prices (such as there were available often cost approaching $1000), or were not available on my home computer, or my laptop. I despaired of Bob Scheifler's and my creation ever having even basic software I saw on Windows or the Mac. Since I wanting to get my job done rather than fight a war that appeared to be lost, I started using a Microsoft desktop for most (not all) of my work a few years ago.
I find, to my surprise, that times have again changed: PC's are cheap, Linux has garnered support of ISV's who build such tools, and the market has grown large enough for PC mass market prices, and it runs on my laptop. I am surprised, amazed and gratified at the revitalization which has taken place in X software development over the last few years. I have grown tired of "blue screens", and crashed editors that leave my file locked. Due to the community's efforts, I am gratefully now in a process of reverting to my roots, despite being impressed with the smooth GUI (graphical user interface) that Windows 98 has these days (on which I happen to be composing this work, having not finished my reconversion). My thanks to all who have made this possible.
But while the current Linux environment is much better than UNIX systems used to be out of the box, it still has a long way to go.
Evolution is fundamental to life. It is also fundamental to progress in computing, since the work required to start over with a fresh system is now so large.
One of the X Window System's greatest strengths has been that it is flexible enough to allow a large range of GUI's to be developed. As such, this fundamentally enabled the GUI wars that started 10 years ago, but has also allowed for its long term evolution (and possibly its survival).
We've seen overlapping window managers, tiling window managers, GUI's looking like NextStep, ones that resemble Microsoft Windows, and many others (including some new ones that make X look like a video game on steroids; it is left as an exercise to the reader to determine if this is a good or bad idea). This strength, unfortunately, is also its greatest weakness.
X applications written 10 years ago are still able to be run 10 years later, without change, and on some systems, without even being relinked (or run across the network from a system that has not been touched in many years). Some of the basic applications are over 10 years old, and look it. They were developed on a VAX lucky to have 2 megabytes of memory, often before any significant toolkit even existed. One widely used application (xterm) even predates X itself (by a month or two); it is now over 14 years old. Or the old application you want has not been touched in years, and uses an old, ugly toolkit that does not look anything like what you want to use.
Many/most of the "out of the box" X utilities in the free core of X need serious rework to get them into the 1990's; many of the CDE replacements, even were CDE available under terms that preserved Linux's attractions, are not particularly good, and are huge. I applaud the Gnome and KDE efforts to rewrite/replace these old utilities.
But if Linux/UNIX/X is ever to break out of the niche of a system for geeks, programmers and for low end servers, the X GUI has to grow up to be something your grandmother might be able to use. And grow up fast. (My mother, as non-technical as you can get, learned to use a Mac at age 75. X is now older than some of the people using it).
End users, however, really, Really, REALLY, would like applications to resemble each other. I certainly have appreciated this consistency anytime I've used an Apple or Microsoft desktop, despite being a programmer myself. It makes it much easier to learn new applications, or relearn those only used occasionally.
But while having a thousand flowers blooming is important, and during X's early development was absolutely vital, for Linux and X to have truly revolutionary impact it must somehow provide a user interface comparable to or better than that on other systems. And the user interface must be able to evolve. I want the applications running on that old machine in the corner I installed with your new GUI you building today be able to at least resemble what it will have become in three or five years.
Otherwise we'll all face the same problem over again, even if a single GUI style and/or toolkit dominates X this generation, if we want the GUI to improve with time. With X, this is actually somewhat more difficult than with Windows, due to X's network nature. You may need to use a system that has not been updated for years across the network. In this case, the old shared libraries never get updated with new ones.
X was designed with a clear separation between "window management" and applications themselves. This has allowed the wide range of X Window managers to be built, including ones that resemble Microsoft Windows, NextStep, and other X specific window managers, including a number of very nice new ones. We clearly succeeded in our attempt to enable experimentation and evolution of window management.
There are several remaining serious design problems, as the GUI style in X applications is only partially in the window manager:
X resources are another attempt at allowing customization that may span time and different toolkits, but have historically been less successful than window managers. How much of this is the approach taken, and how much the result of the GUI wars is not clear to me. In any case, we need a single customization mechanism, that can span both toolkits and time.
The difficulties of matching GUI styles can mostly be handled by shared toolkit libraries, which can hide some of style problems from applications, and handle conventions of interactions between applications, and I would hope, share a single customization mechanism.
So how do we solve this problem and provide a pleasing "out of the box" experience (for your grandmother)? And without throwing the baby out with the bathwater (losing X's characteristic malleability that has allowed so many UI styles to be built, and allow its long term evolution)? And do so such that five or 10 years from now we don't have to do it all over again? And that when a piece of software is installed I don't need to go edit some obscure configuration file somewhere?
At the moment, for better or worse, most commercial X software is Motif based. In the short term, many/most commercial applications will arrive on Linux with the GUI style, whether we like or or not. I've never been fond of Motif (big, bloated, slow, and not particularly pretty). One solution would be (for applications and toolkits themselves) to adopt that style guide, and be done with it. But there goes the baby with the bathwater, and I'd hardly call this a long term solution.
But how do we get even an approximation of a uniform style across toolkits?
I believe there will have to be serious, coordinated work on customization (sometimes called "themes" in some toolkits) in all the various toolkits people are building, so that I can choose the style I like without having some applications appearing in one GUI style, and other applications in a different style. Such customization also helps solve both internationalization needs and the needs of people with disabilities (like your (grand)mother who needs big type on the screen).
Your religion is not my religion. Today's toolkit in one language gives way to another in another language tomorrow. The style of five years from now won't be the same as the style today. One size does not fit all.
You aren't going to get the thousands of existing applications to be rebuilt against N different toolkits to get this consistent style. Those who fail to learn from history are doomed to repeat it. Look where the GUI wars got either OpenLook or Motif.
As a result, I believe that any toolkit that does not allow full customization or cannot be customized to look like the other toolkit's default style should be considered broken. The sooner people accept the premise that all toolkits should be configurable to closely match other styles (and future styles) as a minimum of all future X toolkit development, the better, and that the less grief we will all have.
For then, five or ten years from now, you will be able to make that old application (possibly on that old machine in the corner on the network you haven't touched in years) have a style that at least slightly resembles the truly wonderful new GUI style you are all developing. (Rather than today's amazing clash between the new applications and some of the old.)
Of course, we will find that some GUI idioms are difficult or impossible to map to a different style, but at least most applications will be able provide the same basic style. I am speaking here of the typical menu/dialog box toolkit based application, rather than the small minority of applications that are essentially entirely user interface (e.g. graphics editors).
Serious work is needed on GUI customization, particularly when new applications are installed, needs serious work and standardization across window managers. Manually editing yet another obscure .rc file to add the latest application I installed to a startup menu is not my idea of being "user friendly". I should be able to change window managers and have the applications change to match.
So we'd better revive serious work on the ICCCM (Inter-Client Communications Conventions) so that the applications, even if built with different toolkits, can inter operate well, and some (preferably a single) resource mechanism is essential for customization.
We should also exploit one of X's strengths, insufficiently exploited in most existing toolkits: the ability to embed an application in a subwindow should be routinely exploited, rather than just by window managers. Any simple text window ought to be able to be my favorite text editor, not yet again a different editor with different bindings that I don't like or know. Software should be designed to be modular; I should be able to embed almost any application into my application.
The sooner toolkits allow me to embed my tool into an application easily, the sooner I can have my editor (or other tool) where I want it, rather than the silly braindead one that isn't what I want, or need, or know how to use. And a single instance of an tool may be able to handle many applications simultaneously, rather than consume lots of system resources. Conversely, as an application developer, it means having to write less code to build my application.
This is the only way to avoid huge, bloat-ware applications in which, for example, I face a different text editor for each application. And it means I should be able to use my new favorite tool in the old application.
Audio is becoming more common in real world applications. X is network transparent; there should be an analogous audio server. Believe me, it is best if it is an independent server, rather than an X extension; the reasons are too long for this message. There have been several prototypes built (including one I helped build); one should be fleshed out and become "standard"; or your network transparent window system will be very quiet. The Internet is finally becoming ubiquitous, so if the current local audio only situation continues, you've missed one of the major points of what X was about in the first place.
WIMP (Windows, Icons, Menus, and Pointing) graphical user interfaces typified by Windows of any flavor are not the final word. GUI's may become the minority computer user interface. Hands free interfaces are already of serious interest due to recent improvements in speech recognition, much faster machines and cheap memory. Some of us (e.g. Bob Scheifler, Keith Packard, Richard Stallman, and many others) have been forced into the the brave new world of speech recognition to control their applications due to carpal tunnel syndrome. Speech recognition technology is already entering the retail mass market, and will continue to improve. User interfaces must be usable from speech recognition systems (and without having to retrofit each application). While Xt has enabling facilities for such helper applications to be built, other toolkits may not, and toolkit developers need accept this as a goal. And if we want a mass Linux/X market, there should be a single facility, rather than one that differs between each toolkit.
The next logical step beyond hands free interfaces are eye free user interfaces. Here, I mean the ability to use many or most applications without looking at them. I'd like to use the Web in my car ("Go to the Boston Traffic page; read me the page"), but I sure want to leave my hands on the steering wheel (which is why Cell Phones are causing traffic accidents). By proper use and/or augmentation of ICCCM conventions, and by good exploitation of X's selection mechanism to be able to get the contents of a window in something other that "bits", it should be possible to build X toolkits which would enable eye free use of many or most GUI applications.
Such work will also enable a new class of devices and applications (I like seeing Linux running on 2 AAA cells in a hand held device at 200 mhz), where keyboards don't fit well or at all, and while there might be a screen, it isn't what you might call large. I'd like to be able to use many applications in new environments without a rewrite. The blind will also thank you for this work, even if it is done for selfish motives. As the user base gets large, the need for disability access becomes more and more acute (and painful to retrofit). Windows and MacOS both left this to very late and are having trouble retrofitting the needed functionality. There is much to learn from the Microsoft and Java accessibility work that should go into new X toolkits. And again, we need a single mechanism, rather than a mechanism per toolkit, if at all possible.
We should look forward to the future as well as to the past.
A part of X's fundamental vision and the Web's are similar. You should be able to get your work done anywhere, anytime, from anywhere in the network.
From a user's point of view, there should be little or no difference between local resources and the Web (a very different statement than "the Web should become part of the operating system"). So don't presume that just because a given application has had its own X GUI user interface that it should have an X GUI in the future. Often applications are better integrated as part of the Web, available anywhere, from any desktop, rather than as independent applications. As the Web's functionality matures, more and more applications should be able to be built in this universal fashion.
Application developers should ask themselves today when building any application if it might better be implemented using Web and its technologies, than in X. Sometimes it should, and sometimes it shouldn't. But if you haven't asked yourself the question, you may make the wrong decision.
I should set another thing straight while I'm blathering on. While I never believed extension languages were the panacea that the NeWS advocate claimed ten years ago, my own biggest problem with NeWS was the choice of PostScript as the extension language. (I'm an old Forth programmer myself; I understand both the strengths and the weaknesses of such languages.) James Gosling (author of NeWS) learned the lesson. His language is called "Java". He even worried about the protection model seriously this time. You might have even heard of him and it by now. :-) How should Java play in the X world? Client side only? an X extension? And meet the other goals noted above? I'm not sure. But it is well worth thinking about.
Copyright law is intended to serve the social goal of enabling an author to be rewarded for their efforts, thereby encouraging intellectual activity. One of copyright's unique qualities is that, in effect, you are writing the law when you write the copyright. Without copyright law, it clear that there would be much less intellectual effort of any kind, as authors need to eat.
But rewards can take many forms: satisfaction, getting contributions from others, leveling a competitive playing field, and so on, rather than being monetary. I have no problems with anyone deciding that their effort should have a monetary reward. Charging for software is not evil; it may be the only way to fund an activity that we need done. This is basic economics.
As the drafter of the original X copyright, I've given this some thought. My analysis in 1986 was that the X copyright was the most likely way to achieve the goals of the X project and the goals of Project Athena (exploiting computing in undergraduate education): what we needed were applications; the base technology has no value with out them. I think that X succeeded until toolkits that people depended on started sporting copyrights and licenses that meant that any application might owe royalties to someone. At the time, there were only a few toolkits that were high enough quality to build serious applications. This is clearly no longer the case.
I'm not a fan of the GPL. It can have the effect of inhibiting commercial support and enhancement of a system. For example, a vendor may see making bug fixes and/or minor enhancements worth funding if they can temporarily benefit. In the long run, not having to fix the same bug or reintegrate the enhancement in the next X release generally caused most of this development effort to be given back to the X community. But there may be circumstances in which the (L)GPL may be most appropriate and there are times when an even less restrictive copyright (e.g. X or BSD) is more appropriate, and for a commercial software vendor, a highly restrictive copyright may be appropriate. What is appropriate is ultimately the author's business (unfortunately, some authors never consider copyright before release).
We build on each other's shoulders. Therefore, the toolkit (and library) questions that faces UNIX/Linux and Open Source development can get complicated, since the copyright and/or licenses of what we depend on may affect what rights we have over our own intellectual work. I am therefore concerned that the base system not restrict what I can do with my intellectual effort.
Software authors need to understand basic copyright and license issues both for their own software and software they depend on.
Given the experience of X's previous history, and the copyright/license of the basic Linux system environment, I strongly believe that any "standard" toolkit should be fully unencumbered in the X/BSD or LGPL sense, or it may in the long term defeat development of applications that we all want and need.
All this is hard. It may sound utopian. And choosing a "default" style that most naive people can use is very hard. Various groups will have to cooperate (e.g. LessTif, Enlightenment, TK, KDE, Java toolkits, Gnome). There will need to be "standards" work for resource customization, installation of software and the ICCCM extensions for interoperability. It is more things to do, on top of building a GUI, which is already known to be difficult. Building the tools to set up different toolkit's customization to present a unified GUI "style" will be hard, painful grunt work. And end users must be able to set styles without being a X resource guru. It will be a challenge to all involved. But it is all absolutely essential for user interfaces to be able to evolve and thrive. The energy I see in this community makes me believe it can be done.
Or we can get out our swords, fight each other for a while, and end up falling on the swords, as happened in the UNIX GUI religious wars of ten years ago. And the GUI fundamentalists will win again. Been there, done that, and I guarantee it hurts. And Linux/UNIX/X will remain in niches, and never achieve what it should.
I prefer plowshares to swords, myself.
Jim Gettys, October 30th, 1998