Tuesday 22 July 2008

[edit] Design
For more details on this topic, see X Window System protocols and architecture.
For more details on this topic, see X Window System core protocol.
X uses a client-server model: an X server communicates with various client programs. The server accepts requests for graphical output (windows) and sends back user input (from keyboard, mouse, or touchscreen). The server may function as:
an application displaying to a window of another display system
a system program controlling the video output of a PC
a dedicated piece of hardware.
This client-server terminology — the user's terminal as the "server", the remote or local applications as the "clients" — often confuses new X users, because the terms appear reversed. But X takes the perspective of the program, rather than that of the end-user or of the hardware: the local X display provides display services to programs, so it acts as a server; any remote program uses these services, thus it acts as a client.

In this example, the X server takes input from a keyboard and mouse and displays to a screen. A web browser and a terminal emulator run on the user's workstation, and a system updater runs on a remote server but is controlled from the user's machine. Note that the remote application runs just as it would locally.
The communication protocol between server and client operates network-transparently: the client and server may run on the same machine or on different ones, possibly with different architectures and operating systems, but they run the same in either case. A client and server can even communicate securely over the Internet by tunneling the connection over an encrypted network session.
An X client itself may contain an X server having display of multiple clients. This is known as "X nesting". Open-source clients such as Xnest and Xephyr support such X nesting.
To start a remote client program displaying to a local server, the user will typically open a terminal window and telnet or ssh to the remote client application or shell and request local display/input service (e.g. export DISPLAY=[user's machine]:0 on a remote machine running bash). The client application or shell then connects to the local server, servicing a display and input session to the local user. Alternatively, the local machine may run a small helper program to connect to a remote machine and start the desired client application there.
Practical examples of remote clients include:
administering a remote machine graphically
running a computationally intensive simulation on a remote Unix machine and displaying the results on a local Windows desktop machine
running graphical software on several machines at once, controlled by a single display, keyboard and mouse.

[edit] Principles
In 1984, Bob Scheifler and Jim Gettys set out the early principles of X:
Do not add new functionality unless an implementor cannot complete a real application without it.
It is as important to decide what a system is not as to decide what it is. Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion.
The only thing worse than generalizing from one example is generalizing from no examples at all.
If a problem is not completely understood, it is probably best to provide no solution at all.
If you can get 90 percent of the desired effect for 10 percent of the work, use the simpler solution. (See also Worse is better.)
Isolate complexity as much as possible.
Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.
The first principle was modified during the design of X11 to: "Do not add new functionality unless you know of some real application that will require it."
X has largely kept to these principles since. The reference implementation is developed with a view to extension and improvement of the implementation, whilst remaining almost entirely compatible with the original 1987 protocol.

[edit] User interfaces
X deliberately contains no specification as to application user interface, such as buttons, menus, window title bars and so on. Instead, user software – such as window managers, GUI widget toolkits and desktop environments, or application-specific graphical user interfaces – provide/define all such details. As such, it isn't possible to point to a "typical" X interface as at most times several interfaces have been popular among users.
A window manager controls the placement and appearance of application windows. This may have an interface akin to that of Microsoft Windows or of the Macintosh (examples include Metacity in GNOME, KWin in KDE or Xfwm in Xfce) or have radically different controls (such as a tiling window manager). The window manager may be bare-bones (e.g. twm, the basic window manager supplied with X, or evilwm, an extremely light window manager) or offer functionality verging on that of a full desktop environment (e.g. Enlightenment).
Many users use X with a full desktop environment, which includes a window manager, various applications and a consistent interface. GNOME, KDE and Xfce are the most popular desktop environments. The Unix standard environment is the Common Desktop Environment (CDE). The freedesktop.org initiative addresses interoperability between desktops and the components needed for a competitive X desktop.
As X is responsible for keyboard and mouse interaction with graphical desktops, certain keyboard shortcuts have become associated with X. Control-Alt-Backspace typically terminates the currently running X session, while Control-Alt in conjunction with a function key switches to the associated virtual console. Note, however, that this is an implementation detail left to an individual X server and is by no means universal; for example, X server implementations for Windows and Macintosh typically do not provide these shortcuts.

[edit] Implementations
The X.Org reference implementation serves as the canonical implementation of X. Due to liberal licensing, a number of variations, both free and proprietary, have appeared. Commercial UNIX vendors have tended to take the reference implementation and adapt it for their hardware, usually customising it heavily and adding proprietary extensions.

Cygwin/X running rootless on Microsoft Windows XP. The screen shows X applications (xeyes, xclock, xterm) sharing the screen with native Windows applications (Date and Time, Calculator).
Up to 2004, XFree86 provided the most common X variant on free Unix-like systems. XFree86 started as a port of X for 386-compatible PCs and, by the end of the 1990s, had become the greatest source of technical innovation in X and the de facto standard of X development.[2] Since 2004, however, the X.Org reference implementation, a fork of XFree86, has become predominant.
While computer aficionados most often associate X with Unix, X servers also exist natively within other graphical environments. Hewlett-Packard's OpenVMS operating system includes a version of X with CDE, known as DECwindows, as its standard desktop environment. Apple's Mac OS X v10.3 (Panther) and up includes X11.app, based on XFree86 4.3 and X11R6.6, with better Mac OS X integration. Third-party servers under Mac OS 7, 8 and 9 included MacX.
Microsoft Windows does not come with support for X, but many third-party implementations exist, both free software such as Cygwin/X, Xming and WeirdX; and proprietary products such as Xmanager, MKS X/Server, Exceed and X-Win32. They normally serve to control remote X clients.
When another windowing system (such as those of Microsoft Windows or Mac OS) hosts X, the X system generally runs "rootless", meaning

No comments: