[techtalk] desktops and window managers?

[Daniel Manrique]

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 :)



On Thu, 17 May 2001 stephanie1200 at netscape.net wrote:

> ok, would anyone out there like to tackle the task of explaining
> exactly what the difference is?  I am baffled by why gnome/kde does,
> vs what sawmill/enlightenment/kwm do, how they interact, which ones
> are which...is windowmaker a window manager or desktop? I forget...
> 
> I know window managers change the way title bars and stuff look, but
> beyond the cosmetics, I don't get it.
> 
> Also, what is Motif?  and in an environment with, say, gnome, sawmill,
> and a local x server, which part is serving widgets, which part is
> interpeting them with look and feel, and what else is going on?


	- Roadmaster

----------------
*
Save a tree- use E-Mail!			roadmr at entropia.com.mx
*