X Window System Architecture Overview HOWTO Daniel Manrique [email protected] Revision History Revision 1.0.1 2001−05−22 Revised by: dm Some grammatical corrections, pointed out by Bill Staehle Revision 1.0 2001−05−20 Revised by: dm Initial LDP release. This document provides an overview of the X Window System's architecture, give a better understanding of its design, which components integrate with X and fit together to provide a working graphical environment and what choices are there regarding such components as window managers, toolkits and widget libraries, and desktop environments. X Window System Architecture Overview HOWTO Table of Contents 1. Preface..............................................................................................................................................................1 2. Introduction.....................................................................................................................................................2 3. The X Window System Architecture: overview...........................................................................................3 4. Window Managers..........................................................................................................................................4 5. Client Applications..........................................................................................................................................5 6. Widget Libraries or toolkits...........................................................................................................................6 7. What we have so far........................................................................................................................................7 8. Desktop environments to the rescue..............................................................................................................8 9. Specific Desktop Environments.....................................................................................................................9 10. How it all fits together................................................................................................................................10 11. A day in the life of an X system.................................................................................................................11 12. Copyright and License................................................................................................................................12 i 1. Preface This document aims to provide an overview of the X Window System's architecture, hoping to give people a better understanding of why it's designed the way it's designed, which components integrate with X and fit together to provide a working graphical environment and what choices are there regarding those components. We explore several concepts that get mentioned a lot but might be a bit unclear for those without a technical background, such as widgets and toolkits, window managers and desktop environments. Some examples of how these components interact during day−to−day use of applications are provided. This document is, deliberately, not too technically oriented. It's based on the author's (empirical) knowledge of the subject, and while it's primarily meant as a non−technical introduction, it can certainly benefit from any kind of comments, further examples and explanations, and technical corrections. The author welcomes all questions and comments regarding this document and can be reached at [email protected]. 1. Preface 1 2. Introduction Back when UNIX was a new thing, around 1970, graphical user interfaces were only a weird thing being played with in a laboratory (Xerox's PARC to be precise). Nowadays, however, any operating system in hopes of being competitive needs to have a GUI subsystem. GUIs are supposed to be easier to use. This is not much of a concern under UNIX, which has traditionally been, to some extent, pretty user−hostile, preferring versatility over ease of use. However, there are several reasons why a GUI is desirable even on a UNIX system. For instance, given UNIX's multitasking nature, it's natural to have a lot of programs running at any given time. A GUI gives more control over how things are displayed on−screen, thus providing with better facilities for having a lot of programs on−screen at the same time. Also, some kinds of information are better displayed in graphical form (some, even, can only be displayed in graphical form; like pr0n and other inherently graphical data). Historically, UNIX has had a lot of improvements done by academic types. A good example is the BSD networking code added to it in the late 1970's, which was, of course, the product of work at the University of California at Berkeley. As it turns out, the X Window System (also called X, but never X Windows), which is the foundation for most GUI subsystems found in modern UNIX (unices?), Linux and the BSD's included, was also the result of an academic project, namely the Athena project at the Massachusetts Institute of Technology (MIT). Unix has been a multiuser, multitasking, timesharing operating system since its beginnings. Also, since the incorporation of networking technologies, it's had the ability to allow a user to connect remotely and perform work on the system. Previously this was accomplished either via dumb serial terminals, or network connections (the legendary telnet). When the time came to develop a GUI system that could run primarily under Unix, these concepts were kept in mind and incorporated into the design. Actually, X has a pretty complex design, which has often been mentioned as a disadvantage. However, because of its design, it's also a really versatile system, and this will become quite clear as we explain how all the parts comprising a GUI under Unix fit together. Before taking a look at X's architecture, a really brief tour of its history, and how it ended up on your Linux system, is in order. X was developed by the Athena project, and released in 1984. In 1988 an entity called the "X Consortium" took over X, and to this day handles its development and distribution. The X specification is freely available, this was a smart move as it has made X almost ubiquitous. This is how XFree86 came to be. XFree86 is the implementation of X we use on our Linux computers. XFree86 also works on other operating systems, like the *BSD lineage, OS/2 and maybe others. Also, despite its name, XFree86 is also available for other CPU architectures. 2. Introduction 2 3. The X Window System Architecture: overview X was designed with a client−server architecture. The applications themselves are the clients; they communicate with the server and issue requests, also receiving information from the server. The X server maintains exclusive control of the display and services requests from the clients. At this point, the advantages of using this model are pretty clear. Applications (clients) only need to know how to communicate with the server, and need not be concerned with the details of talking to the actual graphics display device. At the most basic level, a client tells the server stuff like "draw a line from here to here", or "render this string of text, using this font, at this position on−screen". This would be no different from just using a graphics library to write our application. However the X model goes a step further. It doesn't constrain the client being in the same computer as the server. The protocol used to communicate between clients and server can work over a network, or actually, any "inter−process communication mechanism that provides a reliable octet stream". Of course, the preferred way to do this is by using the TCP/IP protocols. As we can see, the X model is really powerful; the classical example of this is running a processor−intensive application on a Cray computer, a database monitor on a Solaris server, an e−mail application on a small BSD mail server, and a visualization program on an SGI server, and then displaying all those on my Linux workstation's screen. So far we've seen that the X server is the one handling the actual graphics display. Also, since it's the X server which runs on the physical, actual computer the user is working on, it's the X server's responsibility to perform all actual interactions with the user. This includes reading the mouse and keyboard. All this information is relayed to the client, which of course will have to react to it. X provides a library, aptly called Xlib, which handles all low−level client−server communication tasks. It sounds obvious that, then, the client has to invoke functions contained within Xlib to get work done. At this point everything seems to be working fine. We have a server in charge of visual output and data input, client applications, and a way for them to communicate between each other. In picturing a hypothetical interaction between a client and a server, the client could ask the server to assign a rectangular area on the screen. Being the client, I'm not concerned with where i'm being displayed on the screen. I just tell the server "give me an area X by Y pixels in size", and then call functions to perform actions like "draw a line from here to there", "tell me whether the user is moving the mouse in my screen area" and so on. 3. The X Window System Architecture: overview 3 4. Window Managers However, we never mentioned how the X server handles manipulation of the clients' on−screen display areas (called windows). It's obvious, to anyone