519 lines
29 KiB
Plaintext
519 lines
29 KiB
Plaintext
|
X Window System Architecture Overview HOWTO
|
|||
|
|
|||
|
Daniel Manrique
|
|||
|
|
|||
|
roadmr@entropia.com.mx<6D>
|
|||
|
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.
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
Table of Contents
|
|||
|
1. Preface
|
|||
|
2. Introduction
|
|||
|
3. The X Window System Architecture: overview
|
|||
|
4. Window Managers
|
|||
|
5. Client Applications
|
|||
|
6. Widget Libraries or toolkits
|
|||
|
7. What we have so far
|
|||
|
8. Desktop environments to the rescue
|
|||
|
9. Specific Desktop Environments
|
|||
|
10. How it all fits together
|
|||
|
11. A day in the life of an X system
|
|||
|
12. Copyright and License
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
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 roadmr@entropia.com.mx.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
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.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
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.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
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
|
|||
|
who's ever used a GUI, that you need to have control over the "client
|
|||
|
windows". Typically you can move and arrange them; change size, maximize or
|
|||
|
minimize windows. How, then, does the X server handle these tasks? The answer
|
|||
|
is: it doesn't.
|
|||
|
|
|||
|
One of X's fundamental tenets is "we provide mechanism, but not policy". So,
|
|||
|
while the X server provides a way (mechanism) for window manipulation, it
|
|||
|
doesn't actually say how this manipulation behaves (policy).
|
|||
|
|
|||
|
All that mechanism/policy weird stuff basically boils down to this: it's
|
|||
|
another program's responsibility to manage the on-screen space. This program
|
|||
|
decides where to place windows, gives mechanisms for users to control the
|
|||
|
windows' appearance, position and size, and usually provides "decorations"
|
|||
|
like window titles, frames and buttons, that give us control over the windows
|
|||
|
themselves. This program, which manages windows, is called (guess!) a "window
|
|||
|
manager".
|
|||
|
|
|||
|
"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."
|
|||
|
|
|||
|
The X architecture provides ways for a window manager to perform all those
|
|||
|
actions on the windows; but it doesn't actually provide a window manager.
|
|||
|
|
|||
|
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, where do you want them to be, and so on. Some window managers
|
|||
|
are simplistic and ugly (twm); some are flashy and include everything but the
|
|||
|
kitchen sink (enlightenment); and everything in between; fvwm, amiwm, icewm,
|
|||
|
windowmaker, afterstep, sawfish, kwm, and countless others. There's a window
|
|||
|
manager for every taste.
|
|||
|
|
|||
|
A window manager is a "meta-client", whose most basic mission is to manage
|
|||
|
other clients. Most window managers provide a few additional facilities (and
|
|||
|
some provide a lot of them). However one piece of functionality that seems to
|
|||
|
be present in most window managers is a way to launch applications. Some of
|
|||
|
them provide a command box where you can type standard commands (which can
|
|||
|
then be used to launch client applications). Others have a nice application
|
|||
|
launching menu of some sort. This is not standardized, however; again, as X
|
|||
|
dictates no policy on how a client application should be launched, this
|
|||
|
functionality is to be implemented in client programs. While, typically, a
|
|||
|
window manager takes on this task (and each one does it differently), it's
|
|||
|
conceivable to have client applications whose sole mission is to launch other
|
|||
|
client applications; think a program launching pad. And of course, people
|
|||
|
have written large amounts of "program launching" applications.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
5. Client Applications
|
|||
|
|
|||
|
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 (scrollbars, radio boxes) 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 usually
|
|||
|
known as "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. Examples of widgets include menus, buttons, radio
|
|||
|
buttons, scrollbars, and canvases.
|
|||
|
|
|||
|
A "canvas" is an interesting kind of widget, because it's basically a
|
|||
|
sub-area within the client where i can draw stuff. Understandably, since I
|
|||
|
shouldn't use Xlib directly, because that would interfere with the widget
|
|||
|
library, the library itself gives a way to draw arbitrary graphics within the
|
|||
|
canvas widget.
|
|||
|
|
|||
|
Since the widget library is the one actually drawing the elements on-screen,
|
|||
|
as well as interpreting user's actions into input, the library used is
|
|||
|
largely responsible for each client's aspect and behavior. From a developer's
|
|||
|
point of view, a widget library also has a certain API (set of functions),
|
|||
|
and that might define which widget library i'll want to use.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
6. Widget Libraries or toolkits
|
|||
|
|
|||
|
The original widget library, developed for the Athena Project, is of course
|
|||
|
the Athena widget library, also known as Athena Widgets. It's very basic,
|
|||
|
very ugly, and the usage is not intuitive by today's standards (for instance,
|
|||
|
to move a scrollbar or slider control, you don't drag it; instead, you click
|
|||
|
the right button to scroll up and the left button to scroll down). As such,
|
|||
|
it's pretty much not used a lot these days.
|
|||
|
|
|||
|
Just as it happens with window managers, there are a lot of toolkits, with
|
|||
|
different design goals in mind. One of the earliest toolkits is the
|
|||
|
well-known Motif, which was part of the Open Software Foundation's Motif
|
|||
|
graphical environment, consisting of a window manager and a matching toolkit.
|
|||
|
The OSF's history is beyond the scope of this document. the Motif toolkit,
|
|||
|
being superior to the Athena widgets, became widely used in the 1980's and
|
|||
|
early 1990's.
|
|||
|
|
|||
|
These days, Motif is not a popular toolkit choice. It's not free (speech),
|
|||
|
and OSF Motif costs money if you want a developer license (i.e. to compile
|
|||
|
your own programs with it), altough it's OK to distribute a binary linked
|
|||
|
against Motif. Perhaps the best-known Motif application, for Linux users at
|
|||
|
least, is Netscape Navigator/Communicator (prior to Mozilla).
|
|||
|
|
|||
|
For a while Motif was the only decent toolkit available, and there's a lot of
|
|||
|
Motif software around. Of course people started developing alternatives, and
|
|||
|
there are plenty of toolkits, such as XForms, FLTK and a few others.
|
|||
|
|
|||
|
Motif is not heard of much these days, specially in the free software world.
|
|||
|
The reason is that there are now better alternatives, in terms of licensing,
|
|||
|
performance (Motif is widely regarded as quite a pig) and features.
|
|||
|
|
|||
|
One such toolkit, the widely known and used Gtk, was specifically created to
|
|||
|
replace Motif in the GIMP project (one possible meaning of Gtk is "GIMP
|
|||
|
ToolKit, altough, with its widespread use, it could be interpreted as the GNU
|
|||
|
ToolKit). Gtk is now very popular because it's relatively lightweight,
|
|||
|
feature-rich, extensible and totally free (speech). The 0.6 release of the
|
|||
|
GIMP included "Bloatif has been zorched" in the changelog. This sentence is a
|
|||
|
testament to Motif's bloatedness.
|
|||
|
|
|||
|
Another very popular toolkit these days is Qt. It was not too well-known
|
|||
|
until the advent of the KDE project, which utilizes Qt for all its GUI
|
|||
|
elements. We certainly won't get into Qt's licensing issues and the KDE/GNOME
|
|||
|
disjunctive. Gtk gets a lengthy mention because its history as a Motif
|
|||
|
replacement is interesting; Qt gets a brief mention because it's really
|
|||
|
popular.
|
|||
|
|
|||
|
Finally, another alternative worth mentioning is LessTif. The name is a pun
|
|||
|
on Motif, and LessTif aims to be a free, API-compatible replacement for
|
|||
|
Motif. It's not clear to what extent LessTif aims to be used in new
|
|||
|
development, rather than just helping those with Motif code use a free
|
|||
|
alternative while they (conceivably) port their apps to some other toolkit.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
7. What we have so far
|
|||
|
|
|||
|
Up to this point we have an idea of how X has a client-server architecture,
|
|||
|
where the clients are our application programs. Under this client-server
|
|||
|
graphic system, we have several possible window managers, which manage our
|
|||
|
screen real estate; we also have our client applications, which are where we
|
|||
|
actually get our work done, and clients can be programmed using several
|
|||
|
possible different toolkits.
|
|||
|
|
|||
|
Here's where the mess begins. Each window manager has a different approach to
|
|||
|
managing the clients; the behavior and decorations are different from one to
|
|||
|
the next. Also, as defined by which toolkit each client uses, they can also
|
|||
|
look and behave differently from each other. Since there's nothing that says
|
|||
|
authors have to use the same toolkit for all their applications, it's
|
|||
|
perfectly possible for a user to be running, say, six different applications,
|
|||
|
each written using a different toolkit, and they all look and behave
|
|||
|
differently. 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 and feel so
|
|||
|
different. This basically negates the advantage of using a GUI environment in
|
|||
|
the first place.
|
|||
|
|
|||
|
On a more technical standpoint, using lots of different toolkits increases
|
|||
|
resource usage. Modern operating systems support the concept of dynamic
|
|||
|
shared libraries. This means that if I have two or three applications using
|
|||
|
Gtk, and I have a dynamic shared version of Gtk, then those two or three
|
|||
|
applications share the same copy of Gtk, both on the disk and in memory. This
|
|||
|
saves resources. On the other hand, if I have a Gtk application, a Qt
|
|||
|
application, something Athena-based, a Motif-based program such as Netscape,
|
|||
|
a program that uses FLTK and another using XForms, I'm now loading six
|
|||
|
different libraries in memory, one for each of the different toolkits. Keep
|
|||
|
in mind that all the toolkits provide basically the same functionality.
|
|||
|
|
|||
|
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
|
|||
|
don't, and they expect us to open a command-launching box, or use a certain
|
|||
|
key combination, or even 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 we expect from a GUI environment which our scheme
|
|||
|
hasn't covered. Things like a configuration utility, or "control panel"; or 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.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
8. Desktop environments to the rescue
|
|||
|
|
|||
|
Here's where the concept of a desktop environment kicks in. The idea is that
|
|||
|
a desktop environment provides a set of facilities and guidelines aiming to
|
|||
|
standardizing all the stuff we mentioned so that the problems we mentioned
|
|||
|
earlier are minimized.
|
|||
|
|
|||
|
The concept of a desktop environment is something new to people coming for
|
|||
|
the first time to Linux because it's something that other operating systems
|
|||
|
(like Windows and the Mac OS) intrinsically have. For example, MacOS, which
|
|||
|
is one of the earliest graphical user interfaces, provides a very consistent
|
|||
|
look-and-feel during the entire computing session. For instance, the
|
|||
|
operating system provides a lot of the niceties we mentioned: it provides a
|
|||
|
default file manager (the finder), a systemwide control panel, and single
|
|||
|
toolkit that all applications have to use (so they all look the same).
|
|||
|
Application windows are managed by the system (strictly speaking there's a
|
|||
|
window manager working there). Finally, there are a set of guidelines that
|
|||
|
tell developers how their applications should behave, recommend control looks
|
|||
|
and placement, and suggest behaviors according to those of other applications
|
|||
|
on the system. All this is done in the sake of consistency and ease of use.
|
|||
|
|
|||
|
This begs the question, "why didn't the X developers do things that way in
|
|||
|
the first place?". It makes sense; after all, it would have avoided all the
|
|||
|
problems we mentioned earlier. The answer is that in designing X, its
|
|||
|
creators chose to make it as flexible as possible. Going back to the policy/
|
|||
|
mechanism paradigm, the MacOS provides mostly policies. Mechanisms are there,
|
|||
|
but they don't encourage people to play with those. As a result I lose
|
|||
|
versatility; if I don't like the way MacOS manages my windows, or the toolkit
|
|||
|
doesn't provide a function I need, I'm pretty much out of luck. This doesn't
|
|||
|
happen under X, altough as seen before, the price of flexibility is greater
|
|||
|
complexity.
|
|||
|
|
|||
|
Under Linux/Unix and X, it all comes down to agreeing on stuff and sticking
|
|||
|
to it. Let's take KDE for example. KDE includes a single window manager
|
|||
|
(kwm), which manages and controls 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,
|
|||
|
communicating between programs, printing, selecting files, and other things.
|
|||
|
These make the programmer's work easier and standardize the way these special
|
|||
|
features behave. KDE also provides a set of design and behavior 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 launcher panel (kpanel), a standard file manager
|
|||
|
(which is, at the time being, Konqueror), and a configuration utility
|
|||
|
(control panel) from which we can control many aspects of our computing
|
|||
|
environment, from settings like the desktop's background and the windows'
|
|||
|
titlebar color to hardware configurations.
|
|||
|
|
|||
|
The KDE panel is an equivalent to the MS Windows taskbar. It provides a
|
|||
|
central point from which to launch applications, and it also provides for
|
|||
|
small applications, called "applets", to be displayed within it. This gives
|
|||
|
functionality like the small, live clock most users can't live without.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
9. Specific Desktop Environments
|
|||
|
|
|||
|
We used KDE as an example, but it's by no means the earliest desktop
|
|||
|
environment for Unix systems. Perhaps one of the earliest is CDE (Common
|
|||
|
Desktop Environment), another sibling of the OSF. As per the CDE FAQ: "The
|
|||
|
Common Desktop Environment is a standard desktop for UNIX, providing services
|
|||
|
to end-users, systems administrators, and application developers consistently
|
|||
|
across many platforms." The key here is consistency. However CDE wasn't as
|
|||
|
feature-rich and easy as it needed to be. Along with Motif, CDE has
|
|||
|
practically disappeared from the free software world, having been replaced by
|
|||
|
better alternatives.
|
|||
|
|
|||
|
Under Linux, the two most popular desktop environments are KDE and GNOME, but
|
|||
|
they're not the only ones. A quick internet search will reveal about half a
|
|||
|
dozen desktop environments: GNUStep, ROX, GTK+XFce, UDE, to name a few. They
|
|||
|
all provide the basic facilities we mentioned earlier. GNOME and KDE have had
|
|||
|
the most support, both from the community and the industry, so they're the
|
|||
|
most advanced ones, providing a large amount of services to users and
|
|||
|
applications.
|
|||
|
|
|||
|
We mentioned KDE and the components that provide specific services under that
|
|||
|
environment. As a good desktop environment, GNOME is somewhat similar in
|
|||
|
that. The most obvious difference is that GNOME doesn't mandate a particular
|
|||
|
window manager (the way KDE has kwm). The GNOME project has always tried to
|
|||
|
be window manager-agnostic, acknowledging that most users get really attached
|
|||
|
to their window managers, and forcing them to use something that manages
|
|||
|
windows differently would detract from their audience. Originally GNOME
|
|||
|
favored the Enlightenment window manager, and currently their preferred
|
|||
|
window manager is Sawfish, but the GNOME control panel has always had a
|
|||
|
window manager selector box.
|
|||
|
|
|||
|
Other than this, GNOME uses the Gtk toolkit, and provides a set of
|
|||
|
higher-level functions and facilities through the gnome-libs set of
|
|||
|
libraries. GNOME has its own set of programming guidelines in order to
|
|||
|
guarantee a consistent behavior between compliant applications; it provides a
|
|||
|
panel (called just "panel"), a file manager (gmc, altough it's probably going
|
|||
|
to be superseded by Nautilus), and a control panel (the gnome control
|
|||
|
center).
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
10. How it all fits together
|
|||
|
|
|||
|
Each user is free to choose whichever desktop environment feels the best. 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. The range of facilities
|
|||
|
provided by modern desktop environments under Linux also enable some other
|
|||
|
niceties, like component architectures (KDE has Kparts and GNOME uses the
|
|||
|
Bonobo component framework), which allow you to do things like having a live
|
|||
|
spreadsheet or chart inside a word processing document; global printing
|
|||
|
facilities, similar to the printing contexts found in Windows; or scripting
|
|||
|
languages, which let more advanced users write programs to glue applications
|
|||
|
together and have them interact and cooperate in interesting ways.
|
|||
|
|
|||
|
Under the Unix concept of "desktop environment", you can have programs from
|
|||
|
one environment running in another. I could conceivably use Konqueror within
|
|||
|
GNOME, or Gnumeric under KDE. They're just programs, after all. Of course the
|
|||
|
whole idea of a desktop environment is consistency, so it makes sense to
|
|||
|
stick to apps that were designed for your particular environment; but if
|
|||
|
you're willing to cope with an app that looks "out of place" and doesn't
|
|||
|
interact with the rest of your environment, you are completely free to do so.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
11. A day in the life of an X system
|
|||
|
|
|||
|
This is an example of how a typical GNOME session goes, under a modern
|
|||
|
desktop environment in a Linux system. It's very similar to how things work
|
|||
|
under other environments, assuming they work on top of X.
|
|||
|
|
|||
|
When a Linux system starts X, the X server comes up and initializes the
|
|||
|
graphic device, waiting for requests from clients. First a program called
|
|||
|
gnome-session starts, and sets up the working session. A session includes
|
|||
|
things such as applications I always open, their on-screen positions, and
|
|||
|
such. Next, the panel gets started. The panel appears at the bottom (usually)
|
|||
|
and it's sort of a dashboard for the windowing environment. It will let us
|
|||
|
launch programs, see which ones are running, and otherwise control the
|
|||
|
working environment. Next, the window manager comes up. Since we're using
|
|||
|
GNOME, it could be any of several different window managers, but in this case
|
|||
|
we'll assume we're running Sawfish. Finally, the file manager comes up (gmc
|
|||
|
or Nautilus). The file manager handles presentation of the desktop icons (the
|
|||
|
ones that appear directly on the desktop). At this point my GNOME environment
|
|||
|
is ready to work.
|
|||
|
|
|||
|
So far all of the programs that have been started are clients, connecting to
|
|||
|
the X server. In this case the X server happens to be in the same computer,
|
|||
|
but as we saw before, it need not be.
|
|||
|
|
|||
|
We'll now open an xterm to type some commands. When we click on the xterm
|
|||
|
icon, the panel spawns, or launches, the xterm application. It's another X
|
|||
|
client application, so it starts, connects to the X server and begins
|
|||
|
displaying its stuff. When the X server assigns screen space for my xterm, it
|
|||
|
lets the window manager (Sawfish) decorate the window with a nice titlebar,
|
|||
|
and decide where it will be on screen.
|
|||
|
|
|||
|
Let's do some browsing. We click on the Netscape icon on the panel, and up
|
|||
|
comes a browser. Keep in mind that this browser doesn't use GNOME's
|
|||
|
facilities, nor does it use the Gtk toolkit. It looks a bit out of place
|
|||
|
here... also, it doesn't interact very nicely with the rest of the
|
|||
|
environment. I'll open the "File" menu. Motif is providing the on-screen
|
|||
|
controls, so it's the Motif library's job to make the appropriate calls to
|
|||
|
the underlying Xlib, draw the necessary on-screen elements to display the
|
|||
|
menu and let me select the "exit" option, closing the application.
|
|||
|
|
|||
|
Now I open a Gnumeric spreadsheet and start doing some stuff. At some point I
|
|||
|
need to do some work on the xterm I had open, so I click on it. Sawfish sees
|
|||
|
that, and, being in charge of managing windows, brings the xterm to the top
|
|||
|
and gives it focus so I can work there.
|
|||
|
|
|||
|
After that, I go back to my spreadsheet, now that I'm finished I want to
|
|||
|
print my document. Gnumeric is a GNOME application, so it can use the
|
|||
|
facilities provided by the GNOME environment. When I print, Gnumeric calls
|
|||
|
the gnome-print library, which actually communicates with the printer and
|
|||
|
produces the hard copy I need.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
12. Copyright and License
|
|||
|
|
|||
|
Copyright (c) 2001 by Daniel Manrique
|
|||
|
|
|||
|
Permission is granted to copy, distribute and/or modify this document under
|
|||
|
the terms of the GNU Free Documentation License, Version 1.1 or any later
|
|||
|
version published by the Free Software Foundation with no Invariant Sections,
|
|||
|
no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be
|
|||
|
found [http://www.gnu.org/copyleft/fdl.html] here.
|