X Explained

The following is an explanation of the X Window System and Window Managers given by Daniel Manrique on the techtalk linuxchix mailing list a few years back. Reproduced with his consent.

"Damn :)

Tis a pretty long rant, hope i don't get everyone snoring here.

well, in the beginning there was X. X by itself basically provides a way for a server to communicate with clients. The clients tell the server "draw a pixel here" and the server handles actually displaying that pixel on-screen. The interesting part here is that the clients and the server need not be in the same computer. This is one of the niceties of X.

However the facilities X as such provides are pretty spartan. draw lines, pixels, write text on-screen. A client usually works on a rectangular area on the screen, which is called a window, and specifies all those drawing operations relative to its window. When a client starts, it requests a window and the servers gives you a window to work.

Here's the first concept you were asking about. X by itself only assigns a rectangular area on the screen for each client. It has no way of controlling that area; say, moving it, resizing it, or closing the client. That's where the window manager comes to the rescue.

"The window manager in X is just another client -- it is not part of the X window system, although it enjoys special privileges -- and so there is no single window manager; instead, there are many, which support different ways for the user to interact with windows and different styles of window layout, decoration, and keyboard and colormap focus."

So, first, the Window Manager gives us a way to manipulate windows themselves. It's the window manager's responsibility to draw a nice frame and titlebar in each window; actually do something when you drag the titlebar, or resize the window, or press the "close" button.

That's a window manager's most basic functionality. However, most window managers provide functionality like a nice menu for starting applications. The problem here is that, for most window managers, configuring this menu is a complicated task.

there are, of course, a lot of window managers, because since the window manager is an external component, it's (relatively) easy to write one according to your preferences, how you want windows to look, how you want them to behave, and so on.

Let's focus on the client programs for a moment. Imagine you wanted to write a client program from scratch, using only the facilities provided by X. You'd quickly find that Xlib is pretty spartan, and that doing things like putting buttons on screen, text, or nice controls for the users, is terribly complicated.

Luckily, someone else went to the trouble of programming these controls and giving them to us in a usable form; a library. These controls are called "widgets" and of course, the library is a "widget library". Then I just have to call a function from this library with some parameters and have a button on-screen.

There are many widget libraries, each according to the author's preferences in aspect, behavior, and API (application program interface). Among these are the Athena widgets, Motif, GTK, Qt and so on.

Here's another question answered. Motif is a widget library. It gives you facilities for placing buttons, menus and other controls on screen. Motif originated as the OSF's preferred toolkit. It's now not very widely used in the free software world, because there are other toolkits, which are free and possibly less bloated than Motif (the famous "Bloatif has been zorched" quote, uttered by the guys who wrote the GIMP, when they switched to Gtk, is a testament to this).

Let's stop for a moment and put together what we have so far. We have our client-server graphic system (X). We have several window managers which manage our client programs; and we have several toolkits which define the look and feel of our client programs per se.

As you can see here, a user can have any of several different window managers. The user can also have several clients, which aren't necessarily written using the same toolkit. So at any given time I can have six or seven apps, all looking different and behaving different. This creates a mess because behavior between the apps is not consistent. If you've ever used a program written with the Athena widgets, you'll notice it's not too similar to something written using Gtk. And you'll also remember it's a mess using all these apps which look so different. This basically negates the advantage of using a GUI environment in the first place.

There are other problems here. The way of launching programs varies from one window manager to the next. Some have a nice menu for launching apps; others dont, and they expect you to open an xterm and launch all your apps by invoking the commands. Again, there's no standarization here so it becomes a mess.

Finally, there are niceties you expect from a GUI environment which our scheme hasn't covered. Things like a configuration utility, or "control panel"; a graphical file manager. Of course, these can be written as client apps. And, in typical free software fashion, there are hundreds of file managers, and hundreds of system configuration programs, which conceivably, further the mess of having to deal with a lot of disparate software components.

Here's where the concept of a desktop environment kicks in. The idea is that a desktop environment provides a set of facilities aiming to standardizing all the stuff we mentioned. Let's take KDE for example. KDE includes a single window manager (kwm), which defines the behavior of our windows. It recommends using a certain graphic toolkit (Qt), so that all KDE applications look the same, as far as their on-screen controls go. KDE further extends Qt by providing a set of environment-specific libraries (kdelibs) for performing common tasks like creating menus, "about" boxes, program toolbars, and communicating between programs. These make the programmer's work easier and standardize the way these special features behave. KDE also provides a set of guidelines to programmers, with the idea that, if everybody follows them, programs running under KDE will both look and behave very similarly. Finally, KDE provides, as part of the environment, a standard file manager (currently Konqueror), and a global configuration utility (control panel).

You'll notice GNOME provides most of these as well; they prefer using sawfish (altough they have facilities for using other window managers), they use Gtk as their preferred toolkit; provide high-level GUI functions through gnome-libs; the GNOME control panel, and Nautilus as their standard file manager.

The end result is that, if you use an all-kde or all-gnome system, the look and feel of the environment is very consistent; and your applications all interact between them pretty nicely. This just wasn't possible when we had apps written in a hodgepodge of different toolkits.

*phew* hope this helped clear things up :)"