[techtalk] desktops and window managers?

[Scott]

Many thanks Dan!  I am more awake after reading that!  Bravo!

At 01:07 PM 5/17/2001 -0500, Daniel Manrique wrote:

>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
>*
>
>
>
>_______________________________________________
>techtalk mailing list
>techtalk at linuxchix.org
>http://www.linux.org.uk/mailman/listinfo/techtalk