Mac OS X Tiger Unleashed

Introduction to the X Window System

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

At the most obvious level, 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 operating system, 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 operating system and is the cause of certain performance issues that are of some annoyance. As you'll see, however, this separation between display and operating system 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 operating systems with integrated GUI functionality, programs that use the X Window System interface functionality don't 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 way of handling GUI element display, but it leads to the abstraction that's 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 application running on the same machine as the display server are processed as though the client were speaking to the server over the network. A benefit of this model that isn't immediately obvious is that to a user sitting in front of a machine running the X Window System, it's 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 operating system) on any other machine running an X Window System server. Applications running on remote systems aren't trapped in their own view of another system's desktop, but instead are full peers on the desktop right beside applications running on the same machine as the X server. This intermingling of clients displayed from local and remote hosts also isn't limited to just one remote host at a time; instead, any X11 program from any remote host can be displayed and interacted with simultaneously with all the other client programs being displayed by the 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 under development 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 are controlled by yet another separate program, rather than by the X Window System server or the operating system 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 such as title bars for itself, X doesn'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 an application dock or other similar functionality.

The X11 software based on the XFree86 that Apple currently provides contains both a completely separate interface to the X11/Unix side of Mac OS X and also a mode to commingle applications running X11 with Mac OS X native Aqua interface applications. This mixed mode will be the most comfortable for many Mac users because it provides almost seamless integration of X11 clients into the Aqua interface. It does, however, mildly break the normal X11 paradigm because the window management is handled by Aqua and isn't as accessible to the X11 software as a normal X11 window manager would be. Still, for many uses, the convenience of having your X11 windows available in your normal Aqua interface is probably well worth the small loss of control that comes with tying X11 to Aqua.

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're used to, the X Window System server is the application that runs on your local machine and physically draws data to your screen, 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. Clients request the service, which is the display of data regardless of where the clients are. Figure 17.1 shows a typical X11 session with several programs displaying themselves on the X server. Among them are a number of xterms applications similar to Terminal 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 or minimizes things into the dock, the X Window System collapses applications into representative icons.

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 and enables you to run software on remote machines and interact with its interface on your local machine.

In Figure 17.2, you again see the X Window System running on a machine. Other than the difference in a few running applications, there's little to distinguish it from Figure 17.1, which 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 actually running on a machine on the other side of the city from the actual screen.

Because the X11 client software creating these applications doesn't care what X11 server it's talking to, and the X11 server on my machine doesn't care whether the clients talking to it are running on the same machine, these applications function exactly as if they were running on my local machine instead of across the city. It wouldn't matter outside possible slowdowns associated with network delays whether the applications were running across the city or across the planet.

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 email 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, all from your home machine, with the software displayed to wherever you are working. No need to transfer files, to create multiple confusing versions, or to work outside your favorite applications.

• 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 over the network to a machine that has the software and use the software on it. No need to mount remote disks to run the application on your local machine. With X11 you get the ability to display the software's interface wherever you're sitting and run the software on the machine where it's stored.

• 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 on 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's "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, 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 such as mouse events destined for windows that are in the in-window system (as opposed to the window containing the system) is difficult.

Toggling back and forth between the systems has some advantages and some disadvantages. The confusion about the proper target for user events is eliminated, and each system can make full use of the hardware as it was intended to, but integration between the systems is even more difficult. The Apple/XFree86 X11 implementation provides one X Window System mode in which X11 exists as an entirely separate windowing system into which you can toggle. Figure 17.1 shows an X Window System session, and Figure 17.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 displayed, the applications in it keep on running. Although it's not convenient to interoperate between applications in one environment and applications running in the other, it's not a bad way to work, especially if you're mostly using Unix-side applications and not Aqua-native applications.

The other available mode is a surprisingly successful implementation of nonrooted, or rootless, X11 environments. To produce such an environment, the X Window System model must be gutted of its notion of having a root window, and it isn't entirely clear how doing so might affect all possible X11 applications. However, it's clear that it works surprisingly well for at least most applications at this point. In addition, Apple's provided a way to wrap the X Window System applications with an Aqua interface manager, rather than a native X11 interface manager. Figure 17.4 shows an Aqua session with X11 applications running side by side with native Aqua applications. In fact, the web browser in Figure 17.2 is running on a remote machine and is displaying happily integrated with Aqua applications on the local machine.