Double-edged sword

Jim Gettys, one of the first authors of the X Window System, submitted a very deep editorial about the X Window System and its possible future. This article is hard to summarize, because it contains a lot of information, facts, and prompts to properly discuss everything. You just need to sit down and spend a few minutes reading it. Note that the copyright of this editorial is owned by the author, and Freshmeat has been directly licensed to publish it online.

Double-edged sword

Jim Gettys, copyright 1998, all rights reserved-distributed by freshmeat with permission of the author.

Author: Jim Gettys

Translator: Wang Cong 2005.09.20 at xiyou

In the past few years, I have lost track of the X Window System, even though I had a close relationship with its initial development. My interest moved from X to audio work, and then to web.
For my recent work, I need commercial production tools (such as Microsoft Word and PowerPoint) instead of a programmer's system. Although X has well-designed software, such commonly used tools, such as WYSIWYG editor or demo programs, it will not be obtained at a reasonable price (for example, there is usually a price close to $1000), or it will not be available for my home computer or notebook. I was desperate for Bob scheifler and my creations, and it used to even have the same basic software as on Windows or Mac. Because I want to finish my work, instead of fighting a war that seems to fail. A few years ago, I started using Microsoft Desktop in most of my work.
I was surprised to find that the times have changed: personal computers have become cheaper, and Linux has been supported by independent software developers (ISVs) who build such tools, in addition, the market has grown large enough because of the large market price of personal computers and it runs on my laptop. I'm surprised, surprised, satisfied, for the revival that has occurred in X software development a few years ago. I'm tired of blue screens and an editor that locks my files to crash. Thanks to the efforts of the Community, I am now very grateful for being in the process of reversing my roots, despite the smooth gui (graphical user interface) that Windows 98 had in those days) I was deeply impressed (I wrote this article on top, but I have not completed my next change ). I would like to thank all people who have made this possible.
However, although the current Linux environment is much better than the out-of-the-box UNIX system, it still has a long way to go.

Our oil paste contains flies. Customization is the root of evolution.

For life, evolution is the most basic. For computer progress, it is also the most basic, because the work to begin on a brand new system is so huge now.
One of the biggest advantages of the X Window System is that it is flexible enough to develop a wide range of GUI software. Because of this, this basically makes the GUI war that broke out 10 years ago possible, but still allows it to evolve for a long time (maybe with its survival ).
We have seen the overlapping window manager, the tiled Window Manager. The GUI looks like the "Next" interface, just like Microsoft's Windows, there are many other things (including some new video games that make X look like a local area network (a video game on steroids ). Judge whether this is good or bad and leave it to the reader for practice .). Unfortunately, this power is also its biggest weakness.
X applications written 10 years ago can still run after 10 years without any modifications, and in some systems, you do not even need to reconnect (or run from a system that has never been used for many years through the network ). Some of the basic applications have been around for more than 10 years. They were developed on a VAX machine with 2 MB of memory Fortunately, even before useful development tools existed. A widely used application (xterm) is more than 14 years old than X itself (one or two months. Or the old application you want has not been touched for several years, and you are using an old and ugly application. It does not look like a development tool at all.
Many/most out-of-the-box tools in X's free core need to work hard to bring them into 1990s. Many CDE alternatives, even the CDE that can be obtained under the terms that keep Linux attractive is not particularly good, and it is huge. I applaud gnome and KDE for their efforts to rewrite/replace these old tools.
However, if Linux/Unix/X breaks this kind of architecture that is suitable for technical geeks, programmers, and low-end servers (the niche of a system ), x's Gui will grow into something your grandmother can use and grow fast. (My mother, as a non-technical person you can reach, also learns to use Mac at the age of 75. X is older than some people who use it .)
However, end users really, really, really want applications to be similar to each other. Whenever I use an apple or Microsoft Desktop, I certainly appreciate this consistency, although I am a programmer myself. It makes it easier to learn new or re-learn the applications that are occasionally used.
But it is important to make one thousand flowers bloom, and it is absolutely crucial in the early development of X. For Linux and X, there is a real revolutionary impact. It must provide a user interface that can compete with other systems or better than them, and the user interface must be further developed. I want the applications that run on old machines in the corner. The applications that I installed with your new GUI can look like it three or five years later.
On the other hand, we will face the same problem again, even if a single GUI style and (or) Toolkit rule the X Generation, if we want to make such GUI improvements over time. For X, to some extent, this is indeed more difficult than Windows, derived from its network nature. You may need to use a system that has not been updated through the network for several years. In this case, the old shared library will never be upgraded to the new one.
X is designed to have a clear separation between the window manager and applications. This allows the X Window Manager to be built in a wide range, including something like Microsoft Windows, "Next" and other X's unique window manager, including many nice new things. Obviously, we are winning in trying to make this experiment a reality and window management.
There are several other important design issues. The GUI style of X applications is limited to the window manager:
* A Part Of a GUI style is combined into an application (as a toolkit ).
* Applications need to interact with each other (this is called "client interaction conversion ").
* Applications and guis must be further developed.
X's resource is another attempt to allow customization across time and different toolkit, but it is not as successful as the window manager in history. I don't know how much this approach is accepted (this view) and how the GUI war works. In any case, we all need a single user mechanism that spans the Toolkit and time.
The difficulty of matching the GUI style can be solved by a shared tool package library to a large extent. It can also hide style issues in applications and handle interactions between conversion applications, I hope to share a single user mechanism.
So how can we solve this problem and provide a satisfactory "out-of-the-box" experience (for your grandmother )? You don't have to throw anything you don't need (lose X's uniqueness, allow the extensibility of building so many GUI styles, and allow long-term development )? After doing this, do we not have to redo it all in the next five to ten years? When installing a software, do I have to edit some obscure configuration files?
At this moment, good or bad, most commercial X software is based on motif. In the short term, many/most commercial applications will arrive in Linux in the GUI style, whether or not we like it. I have never liked motif (huge, swollen, slow, and not pretty ). One solution is to embrace that style orientation (for applications and the toolkit itself) and use it to accomplish it. However, it is difficult for me to call this a long-term solution.
But how can we use the toolkit to implement a unified style that is even close to each other?
I firmly believe that in a variety of Toolkit built by people, it is necessary to have a serious user-oriented work (sometimes referred to as "theme" in some Toolkit "), so that I can choose my favorite style, instead of making some applications look just a GUI style, while others are a different style. This kind of customization also helps to address international needs and the needs of people who are inconvenient to use (like the big fonts on the screen that your "parent" mother needs ).

There is no "real way"

Your faith is not mine. The toolkit of one language will be replaced by the toolkit of another language tomorrow. Five years later, the style will be different from today's. One size cannot fit all. (One size does not fit all .)
You don't need to re-build thousands of existing applications for n Different toolkit to follow this unified style. Those who cannot learn from history are destined to repeat it. See where the GUI war gets openlook or motif.
Therefore, I believe that any toolkit that does not allow full customization or that cannot be customized into the default style of other Toolkit should be considered incomplete. All Toolkit should be able to be configured close to other styles (including future styles. As a microcosm of all future X development tools, the sooner people accept this premise, the better, the less we will feel.
By that time, you will be able to make the old applications (maybe in the corner you have not touched the old network machine for a few years) there is a style that is at least slightly similar to the New Gui style you are developing and really nice to see (rather than the inconsistency between the new and old applications that are surprising today ).
Of course, we will find that some gui idioms are difficult or cannot correspond to a different style, but at least most applications will be able to provide the same basic style, rather than a very small number of applications (bi-shaped editors) that are essentially all user interfaces ).
Important work needs to be done for GUI customization, especially when new applications are installed and important work needs to be done and standardized through the window manager. Manually edit the confusing. RC file to add the recently installed application to an activation menu, which is not what I mean by "user friendly. I should be able to change the window manager and match the application changes.
Therefore, we recommend that you resume important work on client-side interactive communication conversions (ICCCM, inter-Client Communications conventions. Only such applications, even developed with different toolkit, can work well with each other, and a single (better) resource mechanism is essentially customized.

Modular

We should also explore the strengths of X, which are not fully explored in most existing applications: the ability to embed an application in a subwindow, instead of simply using the window manager. Any simple text window should be my favorite text editor, instead of a different editor with attachments that I don't like or don't know. Software should be designed to be modularized; I should be able to embed any application into my own.
The sooner the Toolkit allows me to easily embed my tools into an application, the sooner I can make my editor (or other tools) into what I want, it's not ridiculous. I don't know how to use what I don't want, what I don't need. A tool instance may be able to process many applications synchronously without consuming many system resources. On the contrary, being an application developer means being able to write less code to build my application.
This is the only way to avoid a huge, bloated application. For example, I am dealing with different text editors for each application. It also means that I should be able to use the new favorite tool in the old application.

The wimp interface is not a future

Audio has become more common in real-world applications. X is network transparent. There should be a simulated audio server. Believe me, if it is an independent server, rather than an extension of X, it is the best; the reason for this information is too long. There are already several build prototypes (including one that I helped build); one that should have actual content and become "standard"; otherwise, your network transparent window system will be very quiet. The Internet will eventually become ubiquitous, so if the current situation of local audio continues, you have lost one of the key points about X in the first place.
The wimp (Windows, icons, menus, and pointing) graphic user interface, which is symbolic of any taste, is not the final world. Gui may become the mainstream of computer user interfaces. Hands Free interface has become quite interesting thanks to recent advances in speech recognition, faster machines and cheaper storage. Some of us (such as Bob scheifler, Keith Packard, Richard Stallman, and many others) have been forced into a completely new world of Speech Recognition to control their applications, because of carpal tunnel syndrome ). Speech recognition technology has entered the People's retail market and will continue to improve. The user interface must be available in the speech recognition system (each application does not have to be updated ). Although XT has a tool that grants rights to build such helper programs, other toolkit may not, and toolkit developers need to accept this as a goal. If we want a Linux/X retail market, we should have a single tool instead of a different toolkit.
In addition to the manual interface, the next inevitable means is to not view the (eye free) user interface. Here, I mean you can use many/most applications without looking at them. I want to use the Internet in my car ("go to the Boston traffic page; read that page for me "), but I certainly want to put my hand on the steering wheel (that's why my mobile phone caused a traffic accident ). Through appropriate use and/or enhanced ICCCM conversion, we can fully explore the optionality mechanism of X to get the content of a window in a non-"bit" form, it should be possible to build an X toolkit that can implement many/Most GUI applications without your eyes.
This kind of work will also make it possible for a new type of devices and applications (I like to see that Linux runs on two AAA components in a MHz handheld device), where the keyboard is not even suitable, but there may be a screen, which is not as big as you say. I like to be able to use a lot of applications in the new environment without writing them again. The blind will also thank you for this kind of work, even if it is motivated by selfishness. As the user base increases, the demand for access by the disabled has become increasingly intense (and the renovation is painful ). Windows and MACOs have dragged this off, and it is difficult to rebuild the required features. I learned a lot from Microsoft and Java usability work, which should be added to the new x toolkit. Again, we need a single mechanism, not every Toolkit, as long as possible.
We should review the past while looking forward to the future.

Network Integration

The basic appearance of X is similar to that of web. You should be able to complete your work anywhere and anytime through the network.
From the user's perspective, the local resources and network resources should be very small or not different (unlike the sentence "The web should be part of the operating system ). Therefore, do not assume that a specific application already has its own X gui. In the future, it should also have an x gui. Typically, applications are well integrated into a part of the Web and can be obtained from any desktop, anywhere, rather than as independent applications. With the improvement of web functions, more and more applications should be able to be built in this general fashion.
When building any application, application developers should ask themselves whether it is better to use the web and its technology to achieve it than on X. Sometimes, but sometimes not. However, if you do not ask yourself this question, you may make a wrong decision.

Java Discussion

When I continue to talk nonsense, I should correct another thing. Although I never believe that the Extended Language is a panacea claimed by advocates of News 10 years ago, my biggest question about news is that it uses postscript as the choice of the Extended Language. (I am an ancient forth programmer myself; I understand the strengths and weaknesses of this language .) James Gosling (author of News) learned the lesson. The language is Java. He even worried about this protection mode this time. You may have heard of him and him. :-) How does Java play a role in the X world? Is it just about the client? An X extension? To achieve the other purposes mentioned above? I'm not sure. But it is worth thinking about.

Copyright

Copyright Law serves the social purpose of enabling the author to reward his efforts, so he encourages intellectual creation. The unique nature of copyright is that, in fact, you are writing the law when writing the copyright. Without copyright law, it is obvious that there will be much less intellectual achievement of any type, because the author needs to eat.
However, there are many forms of return: Yes, get the release from others, create a fair arena (leveling a competitive playing field), and so on, rather than money. I have no doubt that anyone decides that their efforts should be rewarded with money. Billing for software is not bad; it may be the only way to fund the activities we need to do. This is a basic economy.
As the initial author of X copyright, I have already thought about it. In 1986, my analysis was that X's copyright was the most likely way to achieve X's goals and the Athena project (exploring computer technology in Undergraduate Education) goals: what we need is applications. Without them, basic technologies have no value. I think that until the tools that people rely on start to make copyright and license variants-that means that any application may have to collect royalties-X is successful. At this time, only a few tools have sufficient quality to build important applications. This is obviously no longer what we want.
I am not a fan of GPL. It may have a systemic effect of restraining business support and enhancing. For example, the seller may see an incorrect patch and/or an improvement worth investing in, if they can temporarily benefit. In the long run, there is no need to fix the same error or reintegrate this enhancement in the next version of X, which generally leads to a majority of such development efforts to be returned to the X community. However, there may be (l) Situations where GPL is best suited, and there may be less restrictive copyrights (such as X or BSD) that are more suitable, and for a commercial software vendor, A strictly restrained copyright may be more appropriate. What is more suitable is mainly the meaning of the author (unfortunately, some authors never consider copyright before publishing ).
We are based on each other's shoulders. Therefore, the problem of tool kits (and libraries) becomes complex in the face of Unix/Linux and open-source sports, because the copyright and/or license we rely on may affect our rights to our intellectual works. Therefore, I am concerned with basic systems that do not limit what I can do to my intellectual achievements.
Software authors need to understand basic copyrights and release licenses, whether for their own software or the software they rely on.
Considering the historical experience of X and the copyright/license of the basic Linux system environment, I strongly believe that any "standard" Toolkit should be in the absence of obstacles under X/BSD or lgpl, or conquer the development of the applications we want and need.

Is this a utopia?

All of these are difficult. It may sound a little utopia. It is difficult to select a "default" style that most natural persons can use. Different groups will have to work together (such as lesstif, enlightenment, TK, Kde, Java toolkits, gnome ). Resource customization, software installation, and interoperability of ICCCM extensions will all require "standard" work. There are a lot of things to do. We already know the difficulty of building a GUI. Building tools to build a uniform Gui "style" toolkit customization will be difficult and painful. In addition, end users must be able to configure styles without being an x resource expert. For everything, it will be a challenge. However, it is absolutely essential for the user interface to evolve and succeed. The power of what I see in this community makes me confident that it can be done.
Maybe we will pull out our swords, fight each other, stop falling onto the sword, just like what happened in the Unix GUI faith war 10 years ago. In addition, the guis will win again. After that, I have done that, and I promise it is hurt. Linux/Unix/X will continue in that habitat and will never be what it should be.
I like the plow head more than the sword.

Jim Gettys, December October 30, 1998