Hi,
Regarding contributions for the website, I have with me an article which
Rajarshi wrote on X programming which we used in the Cyber Journal .. I'm
attaching the article with this mail, see if it matches the site
requirements, and even if it doesn't, I'm sure it'll be good reading for
everybody on this list .
Riddhi
Lets Talk About X !
---------------------
Rajarshi Guha
<[EMAIL PROTECTED]>
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:
o X Windows provides for the concept of a GUI and hence is based on
an event driven model.
o The X Windows system is built on a client server model.
o 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 :).
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 :
o 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.
o Interprets network messages from clients (I'll get to this later)
o Passes user input to the clients by sending network messages
o Carries out 2D drawing.3D graphics are also possible
by using the PEX extension to X (accessible via the PHIGS or
PEXlib API's)
o 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.
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.
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.
Hopefully in future article's, I'd like to give an intro to Xlib and
then maybe discuss certain of the above topics in more detail.
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.
