Let’s talk about X

Lets Talk About X ! Rajarshi Guha 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:

* X Windows provides for the concept of a GUI and hence is based on an event driven model.
* The X Windows system is built on a client server model.
* X Windows is network based.

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 Smiling. 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 Eye-wink 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 :

* Allows access to the display (see [1]) by multiple clients.This means that you could be running 3 apps on three different (remote or local) computers with all three apps displaying their output in three different windows on your screen.
* Interprets network messages from clients (I’ll get to this later)
* Passes user input to the clients by sending network messages
* Carries out 2D drawing.3D graphics are also possible by using the PEX extension to X (accessible via the PHIGS or PEXlib API’s)
* Maintains complex data structures related to windows, fonts cursors etc,collectively known as resources.These can be shared by clients via resource ID’s.This arrangement helps to reduce the network traffic and also reduces the amount of data to be maintained by the client.
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 us 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 which 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. b>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 :
o Messages which request information.Thus for these types of messages,two network transfers are required (one to send the request and on to receive the requested information)
o Messages which just send info/requests to the server and do not expect any reply.
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. [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.

Leave a Reply

You must be logged in to post a comment.