519 lines
29 KiB
Plaintext
519 lines
29 KiB
Plaintext
X Window System Architecture Overview HOWTO
|
||
|
||
Daniel Manrique
|
||
|
||
roadmr@entropia.com.mx
|
||
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.
|