InformIT: Mac OS X Unleashed > Introduction to the X Window System

Table of Contents

Introduction to the X Window System

In attempting to explain the X Window System, in many ways it will be easier to explain how it is different from the interface that you're accustomed to than it will be to explain how it is similar. Certainly, whether you're from a Mac or a PC background, you're used to a graphical user interface, and both the X Window System and the interface to which you are accustomed display windows with program content and information in them. But beyond this, the X Window System is fundamentally a very different interface than the GUI present on either of the popular desktop operating systems.

At the most obvious, the X Window System is not a built-in part of the operating system. Whereas the Mac OS and Windows graphical user interfaces are intimately tied to the underlying OS, the X Window System is a completely separate system, with no real attachment to the operating system underneath it. This separation makes for inefficiencies in the way the window system interacts with the OS, and is the cause of certain performance issues that will be of some annoyance. As will be shown, however, it also provides a level of flexibility that cannot be readily accomplished with integrated systems.

Also different is the fact that the X Window System functions as a client/server system. Unlike OSes with integrated GUI functionality, programs that make use of the X Window System interface functionality do not actually display GUI elements. Instead they contact a completely separate program, the X server, and request that the server perform whatever display functions they require. This might seem like a bizarre and inefficient fashion of handling GUI element display, but it leads to the abstraction that is another major difference, and one of the sources of the extreme flexibility of the system.

The client/server model utilized for X Window System communication is a network-capable system. Messages requesting display functionality can be passed from client to server over a network connection. In fact, even connections from a client running on the same machine as the server are processed as though the client were speaking to the server over the network. A benefit of this model that is not immediately obvious is that to a user sitting in front of a machine running the X Window System, it is completely transparent whether the programs being displayed on the machine are actually running on that machine or on some other machine. Other than possible delays due to delays in the network, the X Window System server responds identically to programs running on other machines as it does to programs running on its own. Still not sure what this means to you? It means that you can display programs running on any machine anywhere (well, any machine running a Unix-like OS), on any other machine running an X Window System server. This doesn't require some high-priced and proprietary commercial application or an experimental program and protocol; it uses well-established and open source software that has been being developed by the online community for decades.

An additional difference between personal computer windowing systems and the X Window System is that the interface's look and feel is controlled by yet another separate program, rather than by the X Window System server or the OS itself. In the X Window System model, the X server is responsible for handling client display requests for displaying windows. Unless a client specifically draws things like title bars for itself, X won't give them to it. The convention with the X Window System is that a separate program is run to create title bars and to manage user interactions such as moving windows around, iconizing and minimizing windows, and providing application-dock or other similar functionality.

In this chapter, we will cover both the open source XFree86 distribution of X11 and the Tenon Systems XTools distribution. The XFree86 software currently provides a completely separate interface to the Unix side of OS X, and promises to eventually integrate X11 and the OS X–native Aqua interface. Tenon's commercial XTools already provides a surprisingly good integration between X11 windows and the Aqua interface.

Client/Server System

As mentioned briefly earlier, the heart of the X Window System is a server that provides display functionality to client applications. In a slight twist on the terminology that you are used to, the X Window System server is the application that runs on your local machine, and clients are the programs that run anywhere, including on remote machines. When you consider the functionality, this makes sense because a server provides a service: displaying data locally to you. The clients request the service, which is the displaying of data regardless of where the clients are. Figure 19.1 shows a typical X11 session with several programs displaying themselves on the X server. Among them are a number of xterms—applications that are similar to Terminal.app in functionality—as well as a text editor, an application dock, a game, and a mail application. The icons that appear as small computer terminals in the upper left are iconized applications; where the Mac OS uses windowshade title bars, the X Window System collapses applications into representative icons.

Figure 19.1 A typical X11 session with several programs running. The X Window System on a 1024x768 screen is a bit cramped, but still useable.

Remote Application Display

Conveniently, this client/server model, like much of the software designed for Unix, is extremely abstract. Just as the input/output model abstracts the notion of where data comes from and goes to (to the point that it doesn't matter whether the data source is a program, user, or file), the X Window System client/server model doesn't care how the client and server are connected. This allows clients to connect to the server from any location, allowing you to run software on remote machines and interact with its interface on your local machine.

In Figure 19.2, you again see the X Window System running on a machine. Other than the difference in a few running applications, there is little to distinguish it from Figure 19.1. This is exactly the point. In this screenshot, the Web browser, two of the terminal windows (find the ones with host soyokaze in the command prompt), and the game are being displayed from a machine running on the other side of the city from the actual screen. It would not matter—outside possible slowdowns associated with network delays—whether the applications were running across the city or across the planet.

Figure 19.2 Another typical X11 session with several programs running. In this image, several of the windows actually belong to applications running on a remote machine.

The impact of this might not be obvious to you yet, but consider that with this capability, the following become possible:

Have a document at home that you were supposed to edit and e-mail to someone, but you forgot? Just connect to your home machine and fire up your editor with it displayed back to your local machine. Edit your document and send it on its way.
Need to change something in a file and you don't have the software on the machine you're sitting at? No problem, just connect to your normal machine over the network, and use the software on it.
Stuck behind a firewall and can't get to eBay to submit a last-minute bid? Don't tell your boss about this, but using what you know about tunneling connections with slogin, and a Web browser running on your home machine, you've got a recipe to browse from home, no matter where you're currently sitting.

Rooted Versus Nonrooted Displays

A quirk forced upon the X Window System by attempts to get it to coexist with GUIs such as Aqua is the idea of rooted versus nonrooted displays. The X Window System has existed for years under the same impression that Mac OS has—that it is "the" windowing system running on any particular machine. As such, it includes the idea of a root window, much like the Mac OS desktop. The root window is assumed to be a full-screen window that exists behind all other windows in the system, and into which certain restricted types of information can be placed. To make the X Window System coexist with another windowing system that also wants to have a single whole-screen background window, only a few possible compromises can be made. To coexist, either one of the systems has to give up its assumption of supremacy; one or the other could run entirely inside a window in the one that reigns supreme; or both could operate as usual, but display only one at a time, with the user toggling between them. If you've used Timbuktu or VNC before, you've used a system in which one display runs entirely inside a window on the other. There have been X11 implementations for Mac OS that have provided this option for X as well.

Displaying an entire windowing system rooted inside a window in another windowing system is a less than ideal solution. Outside the problem of not really integrating the functionality, and leaving the user with a poor workflow between applications in each of the environments, handling things like mouse events destined for the "in window" system (as opposed to the window containing the system) is difficult. The current XFree86 implementation provides the X Window System functionality as an entirely separate windowing system into which you can toggle. The screenshot in Figure 19.1 shows an X Window System session, and Figure 19.3 shows an Aqua session—these two are actually running on the same machine, at the same time. The X Window System environment can be toggled to by clicking the X icon in the Aqua dock, and the Aqua environment can be toggled to by pressing Command+Option+A. Even when one of the environments isn't being displayed, the applications in it keep on running. Although it's not very convenient to inter-operate between applications running in each, it's not a bad way to work, especially if you're mostly using Unix-side applications and not Aqua-native applications. XFree86's XonX project promises to eventually integrate X11 applications into the Aqua environment. As of this writing, this is not a viable option for any but the most courageous because it requires considerable crossbreeding of Mac OS X, the Darwin project, and additional minimally tested code.

Figure 19.3 This Aqua session is running concurrently with the X11 session shown in Figure 19.1. The window containing what looks like an X11 session is Picture Preview showing the image for Figure 19.2.

Tenon's commercial XTools, on the other hand, is a surprisingly successful implementation of a nonrooted, or rootless X11 environment. To produce such an environment, the X Window System model must be gutted of its notion of having a root window, and it is not entirely clear how doing so might affect all possible X11 applications. However, it is clear that it works surprisingly well for at least most applications at this point. In addition, it manages to wrap the X Window System applications with an Aqua interface manager, rather than a native X11 interface manager. Figure 19.4 shows an Aqua session with X11 applications running side by side with native Aqua applications. In fact, the Web browser in Figure 19.2 is running on a remote machine, and is displaying happily integrated with Aqua applications on the local machine.

Figure 19.4 Tenon's XTools, shown displaying X11 applications side by side with Aqua applications.

Installing the XFree86 OS X Distribution | Next Section

Previous Section