An Introduction To X

When I sat down to write an article on X Windows programming,I began by looking up some code examples and interesting techniques.But then I remembered the various problems I had when I started and I realized that before I could get into any real life examples what was required was a discussion about the various issues facing the budding X programmer.So in this article I'd like to leave out most of the code and rather talk about what makes X what it is.

The structure of the X Window system has three very important features,all of which have an important impact on programming for X.These are:

Consider X and the event driven model.For those who aren't too clear about 'event driven' ,it means that the flow of logic in a program is not necessarily linear but is dependent on external events.That is,the program responds to various inputs from the outside world. Consider a GUI - if you click the mouse on a button something happens;click somewhere else,something else happens and so on.External events do not only include humans pressing a mouse - hardware devices can also generate events.

As such X does not provide a GUI.Rather it provides the 'foundations' for a GUI, by providing various services,in the form of the X Protocol (see [2]) and XLib.Using this (extremely) low level interface to X we could create GUI (it would be analogous to writing Win9x in assembly :).But since most people will be writing X apps this is not of much interest. What ever way a programmer writes his X programs (whether in XLib,Xt,Motif,Gtk,Qt etc) he will have to respond to user events.Basically his program will have some initialization code (say to set up various UI elements and data structures etc) and then his program will enter an infinite loop where he will continuously check for various type of events.These events will be specified in various ways by the various toolkits,but all will be based on the events (and related event data structures) provided by XLib - so having a sound knowledge of XLib is a must for any X programmer.I won't go further into event driven programming,mainly because it is not unique to X - those of you out there who program in VC++/Java etc will know the event driven model quite well.

Next consider the client server aspect of X.
Most of you might not realize that the X Window system is based on a client server model.To a lot of people the client and server are not what they commonly think.In the case of X,the server is the X server running on your system (in most of our systems it will be XF86_SVGA) and the clients are the various X apps (eg. xeyes,xv,xemacs etc) that you run.In networked installations,these client X apps may be running on some other host and only displaying their output on your screen through your server.A good example is running a scientific visualization,where a SGI or Cray carries out the calculations ,generates the images and passes the final graphical output to your screen - thus the humongous calculations are left to the Cray while your lowly PII need only plot the images/graphics etc.This aspect confuses most newcomers (at least I was ;) in the beginning.Consider other client server models like the Web.In this case we run a client (Netscape,IE etc) on our machine and use it to access a server somewhere else on the network.At this point I'd like to diverge and discuss exactly the roles of the server and the client.

Basically the X server is the program that controls what you see on you monitor during an X session.It's functions are that of an intermediary - ie,it manages requests made by local/remote applications for the resources on the system on which it is running.The server's role can be summarized as :

However, in comparison to the server which has certain,specialized and well defined jobs,the client can do anything.In general all client programs can be described as X apps.The only client excluded is the window manager.Apps communicate with the X server by means of XLib calls - these are C function calls which allow an app to use the resources provided by the server.Functions include connecting to specific display,creating windows,drawing graphics, etc.Apps can also be written with the help of toolkits.These provide ready made UI elements (generally known as widgets) and free the programmer with dealing with the nitty gritty of XLib.Toolkits include Motif/Lesstif/Gtk/Qt etc.Examples of apps include xterm (uses XLib),emacs (uses Xaw in the X version), GIMP (uses Gtk) and all the KDE apps (which use Qt).

Now let us consider the network aspects of X.When the system was envisaged the architects (viz.Jim Gettys and Robert Scheifler) had decided that X would be a networked system.Most of don't recognize this fact because our server and our clients are running on one box.But for those lucky enough to have access to networks the actual fun starts.Because in that case,they need only run the X server on their machine and all their client apps can be running somewhere else on the network.And here network does not only include the local one (LAN) but actually anywhere in the world (assuming you have execution permissions on the remote computer!).In general X uses the TCP/IP protocol for network communication.When communicating to clients on the same machine it uses Unix Domain sockets.Due to the networked nature basis of X,it is apparent that certain security risks may arise.As a result various authentication and authorization mechanisms exist by which an admin can specify which server can access host.A well known authentication/authorization system is Kerberos.So what does all this have to do with writing an X client.Well lots!

Firstly,you have to keep in mind that all the GUI related activities must be managed by the client.This apparently contradicts what I had written earlier.But actually the X server will only carry out requests made by a client.So it will draw a rectangular window with certain background, but the client must provide the dimensions,the background color/pixmap, a mask if any and if the client only wants to redraw a portion of the window,the client must calculate which portion and supply that to the server.Thus all drawing related functions must be carried out by the client.

Secondly because the X server will be communicating over a network connection,the client should try and minimize the amount of data sent across the network and the frequency of such transfers.Here the X server helps a great deal by storing 'resources' in it.Thus once a certain window has been created,it's related data structure will contain the fore and background colors,the events requested for the window,various window manager hints etc.Thus when a client app calls some drawing function it need not send all the data describing the window across the network.This can apply to other resources like graphic contexts (GC) which describe the fill pattern,thickness of lines and other graphics related information.Once a GC has been created several apps can use this resource.Thus not only is network traffic reduced overall memory consumption is also reduced too due to the sharing of these resources.To understand how to improve network efficiency,we must take a peek at the sending of messages across the network. There are 2 types of messages :

Clearly the first type of messages are to be minimized,especially in long running loops. Not only will it clog the network but also due to network delays the returned information may be delayed in reaching the client - thus slowing down the program.An important consequence of the networked nature of X is buffering.To improve network efficiency XLib saves up requests (ie,buffers them) and sends them in a batch to the server.This is feasible since a lot of request do not require immediate server action.There are certain conditions which will cause the flushing of the buffer,one of them being manually. However,we leave out the details for another time.But the important thing to note is that due to buffering drawing request will sometimes not appear immediately,until the request buffer is flushed.
An important consequence is during debugging - errors are not found by the server until the request reach it and this only happens when the buffer is flushed.What this means is that several XLib routines may occur before an error in a earlier routine arises.For debugging purposes the buffering can be switched off.As a result as soon as a request generates an error the program will stop.However the client will slow down noticeably.Thus in the final program buffering must be present.
These I think, cover some of the fundamental concepts that an X programmer should be aware of. I'd have liked to give some concrete code & examples which illustrate the topics discussed above,but I think I've gone on for long enough.As it is there are a number of other topics which can be discussed - these include handling of color (and its device independence in X), event handling, windows, i18n, inter client communication etc.And of course I haven't touched XLib itself yet.
To write this article I referred to the XLib Programming Manual by Adrian Nye (published by O'Reilly) and anybody interested in getting into X programming should read the X series published by O'Reilly - these are the definitive guide to all things X. They are of course outrageously expensive so another book you could look at is X Windows System Programming by Nabajyoti Barkakati (PHI).

[1] : In X terminology a 'display' consists of an entire workstation including CPU box, keyboard, mouse and one or more screens.A given workstation can have more than one screen and the server can arrange thins such that the viewing area is distributed over the multiple physical screens.As long as these multiple screens are controlled by a single user with a single mouse/keyboard etc this constitutes a single display.

[2] : The X Protocol specifies what each packet of information sent between the client and server is made up of.In general there are four types of packets : requests, replies, events and errors.Considering an analogy with a computer, the X Protocol is the machine language of the processor, XLib is the corresponding assembly language and the X toolkits are the C language used to program that computer.

THIS ARTICLE IS THE INTELLECTUAL PROPERTY OF OMNILINUX, A SUBSIDIARY OF UNITEK INFORMATION SYSTEMS
Back to top of the page