The X Window System has a very distinct place in Linux history. Originally developed at MIT in 1984, X works with multiple applications simultaneously, generating text and graphics in monochrome, colour and bitmap display. X also provides facilities for generating multi-font text and two-dimensional structures like lines, polygons and circles. X even provides a basic framework for building graphical user interfaces. X is simply another application sitting on the top of the Linux kernel.
To start with, you may be confused between X Window System and Xlib. Actually, X is fundamentally composed of network protocols, which are quite complex, and consist of bits and message transfers. To reduce complexity, different libraries handle the complexity internally, providing programmers with an API. Xlib is the library for the C programming language.
The history and design of X
X was created as a research project in the early 80s. The committee responsible for X is the MIT X Consortium. The lead programmer was Robert Schiefler. In the early 90s, X was ported to run on Linux — an architecture that was known as the XFree86 system. XFree86 provides a client/server interface between the display hardware and the desktop environment.
With X, it was possible, for the first time, to write programs for an entire class of machines, rather than limited to a particular hardware manufacturer. Programmers could write programs that ran on almost any combination of hardwarepossibly without even recompiling them.
Let us now look at the client-server architecture of X. The server is the program that controls the display, while user applications are clients. The server passes user inputs to the respective/active client program, and displays the information provided by the client program. The server acts as an intermediary between clients running on local or remote systems, and the resources of the local or remote system.
The design of X introduced the idea of X terminals — thin clients that ran only an X server and connected to a large server computer to actually run useful programs. These were executed on the server system, and were displayed to the user on the terminal. The X client-server architecture even enabled users to have X programs display their output on a Windows system, while the program itself ran on a UNIX machine — which actually is one of the most significant features of X. The following figure gives a schematic diagram of how this works.
X clients (programs) are written using Xlib to communicate with the X protocol. The X protocol defines each packet of information that is transferred between the server and Xlib, which is in one of the following forms:
- Request (from Xlib to the server): Information like specifications for circles.
- Reply (from server to Xlib): In certain requests, there is a reply.
- Events (from server to Xlib): Information of the user action like a mouse click.
- Errors (to the client): Errors are handled by an error-handling routine in Xlib.
X clients do not actually control display-related attributes like the window size or position. In fact, clients must not be dependent on a particular window configuration, though a client can give hints about how long, and where it would like to be displayed. The screen layout and the style of user interaction with the system, are managed by an X Window manager.
Some of you might be wondering how the requests are handled. Well, Xlib groups requests, instead of sending them one by one. This grouping also helps improve network performance, as the longer and less frequent transfers reduce the overall load.
Normally, after an event arrives at a client, the application generates more requests to drawfor example, highlighting the border of a button when the user moves the mouse pointer over it. These responses stay queued in Xlib, until all the events that have already arrived have been processed.
The schematic diagram above gives a clear picture about the whole process. When an application starts, all the requests that create the initial appearance (like a splash image) are queued up by Xlib. After the initial loading is done, the application waits for user input from the server. After the user activity is detected, the server sends the requests to Xlib.
Please note that the server does not queue or group requests; it acts immediately on any request received from the user or Xlib. Here, Xlib sends the requests to the client in the order in which they were received. In case there is an error, the application throws an error message to the server, and it generates the necessary output.
What’s next?
This article was purely theoretical, and aimed to generate awareness about Xlib. I would personally recommend that you understand all the concepts, to better enable you to write a program in Xlib with a proper flow. This is important, because you have to open and close a connection with the server; undetanding the flow lets you know which function to use at which point in time.
In the next article, I will demonstrate a simple program for plotting a series of points in a graph. The concepts explained in this part will definitely have an impact on your further understanding. See you soon!
