click here to go the full document

Overview of X Windows

X11 Release 5 came out in August 1991. The heart of the X Windows system consists of a program called X which runs on a machine with a display, keyboard, and a mouse. It waits for other programs to tell it what to do or for something to happen to the pointer or keyboard. The programs can be running on the same machine as X is or elsewhere on the network, maybe on a machine that hasn't even got a display of its own. This `network transparency' is one of the strengths of X. Graphics programs only have to know about X, not about the special low level graphics commands for each type of machine. The client programs communicate to X, the server, via a Protocol language that is common across machine types.

All a client program needs to do to use the X display is to open up a connection with the server and then send Protocol requests to it. To simplify sending these, an extensive library of about 200 display subroutines is provided and it is this library, Xlib, which this document mainly describes.

 
Figure 1: X system overview

Many client programs can simultaneously use the same X server. To save each client having its own copy of fonts, color information, etc, (thereby wasting space and causing more data to be passed via the network), the server stores data on behalf of the clients, allowing sharing wherever possible. In order to enable the client to reference these resources the server provides resource codes and these can be used in many of the routines to specify that certain data is to be used.

X is `event driven'. For each window you create you can select what sort of events (key presses, re-exposure, etc) you want it to respond to. Typically, an X program consists of a set-up sequence followed by an `event-loop' which waits for events to be reported by the server, determines what sort of event has happened and in which window, then processes the event.

There are 4 types of messages passing between the client and server;

• Requests - the client can ask the server to draw something, or ask for information.
• Replies - the server can reply.
• Events - the server can surprize the client with something
• Errors - the server can report an error

Both display requests and events are buffered and the server executes asynchronously much of the time to maximise efficient use of the network. When the client wishes to establish synchronization it often has to ask for it, though working in synchronized mode can be up to 30 times slower, so only use it for debugging.

X clients programs should be written mindful of the fact that other clients are likely to be running at the same time. Windows should be prepared to be covered over by others then exposed, and they have to redraw themselves. Neither should clients indescriminately use scarce resources like off-screen memory or monopolise the keyboard or pointer. If they can accept cut-and-paste operations, so much the better.

One application that is always likely to be running is a `window manager'; a program which allows you to resize, move and re-stack windows, pop menus up, etc. Any X application you write will need to work under a window manager. Some window managers are more bossy than others (some won't let you raise windows, for instance), but there are X commands so that a client can at least make suggestions to the window manager.

X can support one or more screens containing overlapping (sub)windows and works on many types of hardware but it doesn't provide high level support. If you want to prefabricate dialog boxes from pre-defined scrollbars, buttons, etc then you should use a `toolkit' that sits on top of X. See the Motif manuals and on-line help for details.

X is extensible. Release 4 of X included the SHAPE extension which provides non-rectangular, disjoint windows. Neither the use or the writing of such extensions will be covered in this document.