X Factor – understanding the X window system
This article was originally written for Tectonic Magazine and appeared in the preview edition.
X was originally created in the mid-80s by a research group from MIT. Its goal was to create a windowing system quite unlike any that had been conceived before. Thus X\’s design differs greatly from that of other windowing systems, having designed-in support for many elements which are unique Â features which in fact are nowadays often being hacked into other windowing systems.
More often than not, such attempts are kludgy and don\’t work well, because they lack the ground-up desig X offers.
X went through a number of iterations because the original releases were not under a copyleft license. Every Unix developer created his own version, usually only modifying small parts, resulting in divergence into many incompatible versions, most of which fell under proprietary licences.
As a result, a standards body was eventually created to oversee the development of X. This body, known as the X Consortium, includes amongt its members IBM, Hewlett Packard and even Microsoft.
Until fairly recently, Linux users generally used a version of X developed by the XFree86 group, which used a free software licence. When XFree86 made a series of license-changes that were deemed to make the software non-free, a fork Â a split into a new line of development Â was created from the last free software version. This fork is called X.org and it is now becoming the de facto standard X version on Linux systems, having superseded XFree86 in many ways.
X is built on a client-server model, and this is where its greatest and unique strengths lie. The X server can be thought of as a communications hub. It relays messages from graphical applications (X clients) to the display hardware, telling it what to draw, and relays other messages from the input hardware back to the clients, telling them what the user did.
The X server thus has two important functions. Firstly, it speaks to the hardware; this means the X server needs to contain the driver for your graphics card, mouse, keyboard etc. Secondly, it speaks to X clients (every X program, from xterm to OpenOffice.org is an X client). Thus no X client ever talks directly to the hardware.
This kind of communication is obviously no simple feat to achieve, and to get all the messages around a special, standardised protocol was defined: The X protocol.
The X protocol
The X protocol is basically a communications protocol. It has an RFC (Request For Comment) that describes it, and is in every way an Internet protocol, similar to, although more complex than, the likes of the pop mail protocol. It can run over a number of different communications channels.
The most common channel is Unix Domain Sockets (UDS, a very fast mechanism for interprocess communication on Unix) which provides the highest speeds for local usage (for example where the X server and X clients are on the same machine). However it can also run over several network protocols, such as TCP/IP, allowing you to use your local X server to run a program on a distant machine over the Internet.
This great ability forms the heart of many innovative usages including LTSP-based (Linux Terminal Server Project) thin-client technology. Basically, it would be possible to create a graphical program by simply writing a program that can open an appropriate channel, connect to an X server and then send and receive X protocol messages over this channel.
This would be the X equivalent of programming in machine code.
It\’s generally not recommended, as this will fill the program with thousands of lines of protocol communications which bear no visible resemblance to the purpose of the program, but it can be done. To the best of my knowledge, however, there are no such programs in active development.
A little bit easier
Luckily, working directly with the X protocol is seldom needed because X also provides xlib. Xlib is essentially a library of standard X tasks, such as basic drawing primitives and event handling. Xlib is written in C (with wrappers to many languages) and it in turn speaks to the X protocol for you. Xlib takes care of the low-level detail part of using the X protocol, such as establishing a connection over the appropriate channel and talking to the server.
As such, all X clients link to xlib, either directly or indirectly. Xlib can be thought of as the X equivalent to using assembler language. It\’s doable, but not very popular. The most common examples of programs using it directly are the X utilities (such as xterm and xcalc) and simple window managers.
X for dummies
Finally, there is the level where most programmers really work. Widget Sets are libraries that link back into xlib for you, expanding on its drawing primitives and providing programmers with what are called widgets. The word widget is derived from window-gadget. They are the little building blocks (such as buttons or text entry fields) that all graphical programs use. Each widget set (also called toolkits) expands on the basic xlib primitives in subtly different ways, giving each its own unique look.
In the first days of X, the most widely used widget set was the proprietary Motif. The Free Software Foundation provides a Motif-compatible library called Lesstif which allows old programs written for it to be used today without requiring this non-free library.
Today the two most important widget sets in the Linux world are GTK and QT respectively. Their importance is greatly enhanced by the fact that these are the two toolkits on which the Gnome and KDE desktops are respectively built. Many other widget sets exist, and although none are as feature-rich as GTK or QT, they are still often used.
GTK is the Gimp ToolKit, as its name indicates it was originally written to provide a toolkit with the features needed by the Gimp (a very popular Linux image editing program). It is written in C and is non-object oriented in its design. QT is a product of Trolltech, originally released under a non-free license. Pressure from the community led to it being dual-licensed today with either a GPL or proprietary version available. QT is written in C++ and provides a powerful object oriented widget set.
Some of the more interesting remaining sets include SWING (the Java widget set) and TK (which is used with TCL language). Recent times have also seen the emergence of meta-widget sets built on top of GTK or QT to provide an even higher level of abstraction.
These are commonly used in multi-platform languages for the Linux specific implementation. WXwindows (from the python world) and the Lazarus Component Library are good examples of meta-widget sets.
Taking the desktop
These days no discussion on X would be complete without mentioning that the last few years has seen the emergence of complete desktop environments for Linux and other Unix\’s on top of X. These expand on their underlying widget sets by providing the needed tools for applications to work in a uniform manner and communicate easily with other applications written for this desktop.
The two most important desktop environments today are of course KDE and Gnome, as most new Linux applications are built for one or the other. Currently KDE and Gnome basically match each other for features and which one a user prefers tend to be a matter of taste rather than a technical decision. Almost all Linux users use one of these two. Old-time Unix users and programmers often shun them however, preferring minimalist desktops.
Seen the movie? Get the book
Should you wish to gain a more complete insight into X, we highly recommend the book: Unix desktop guide to X/Motif by Nabajyoti Barkakati. Unfortunately it\’s been out of print for several years and can be hard to obtain, however some university libraries will have copies.
AJ Venter is lead developer at Direq International which build Linux-based thin client solutions for schools and community centres.