X11 Release 5 came out in August 1991. The heart of the XWindows 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.
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.
Using X from a Terminal
There are a number of window managers, terminal emulators and graphics programs supplied with X which enable the user to create text windows and move them about on the screen.
|xdpyinforeturns info about the X server|
|xset q||returns into on the mouse set-up etc<|
From the programmer's point of view X consists of a library of subroutines
which he may call in order to perform specific functions on the display.
These functions are contained in a library,
/usr/lib/X11R5/libX11.sl on HPs) which must
be linked into the program by the loader when the executable version of
the program is generated. This can usually be done by adding
the end of the compilation command and, on HPs,
the start. The Xlib header file
/usr/include/X11R5/Xlib.h on HPs)must also be
included at the top of every program file which uses the X library. On the
HPs this requires the addition of
The coordinate system for X windows has its origin at the top left hand
corner of any given window. The x coordinate increases from left to
right across the page and the y coordinate increases from top to bottom.
The global coordinate system is effectively
that of the
RootWindow which covers the whole of the screen. The scaling of
coordinates on an X display is never changed,
however operations in each window are performed relative to that window's
X functions which are described as returning
Status produce a non zero
value if they have executed successfully and return zero if they have
failed. Other routines which return a pointer to something on success
usually return the
NULL pointer on failure.
To save space, we have only declared arguments whose type or use is not self evident. Most particularly, the following variables are not declared :-
Display *display; Window w; Drawable d; /* either a window you can draw into or off-screen memory (a pixmap) */ GC gc; /* a Graphics Context, where current font, foreground color, etc is contained*/ Colormap cmap; Region r; unsigned long mask,valuemask;
There is a standard order for arguments :-
display,resources,gc, x,y,w,h, array,array_length, mask,struct
Some of the most useful information on the X library can be
found in the include files
X.h. These files are usually
There are several example programs in this document. More comprehensive
examples are in
/export/Examples/X on the CUED
teaching system and in the
X source tree (/usr/src/X11R4
on the CUED teaching system). Even more examples are available via
Manpages for the routines are online.
The online help facility at CUED contains a file of answers to frequently asked questions and some discussion of advanced topics.
Relevant newsgroups are:- comp.windows.x, comp.sources.x
David Bijl, Tim Marsland and Richard Prager have all made useful comments and suggestions.