189 lines
5.1 KiB
HTML
189 lines
5.1 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Desktop environments to the rescue</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.63
|
|
"><LINK
|
|
REL="HOME"
|
|
TITLE="X Window System Architecture Overview HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="What we have so far"
|
|
HREF="so-far.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Specific Desktop Environments"
|
|
HREF="specific-desktop-environments.html"></HEAD
|
|
><BODY
|
|
CLASS="SECT1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>X Window System Architecture Overview HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="so-far.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="specific-desktop-environments.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="DESKTOP-ENVIRONMENTS"
|
|
>8. Desktop environments to the rescue</A
|
|
></H1
|
|
><P
|
|
>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.</P
|
|
><P
|
|
>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.</P
|
|
><P
|
|
>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.</P
|
|
><P
|
|
>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.</P
|
|
><P
|
|
>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.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="so-far.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="specific-desktop-environments.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>What we have so far</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Specific Desktop Environments</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |