os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

This patch does the following:

Browse source 
- renames this section to "Terminology"

- formats it as individual definitions rather than as individual subsections; this makes the chapter
 less deep heading wise and matches the style used in other sections such as http://www.freebsd.org/
doc/en_US.ISO8859-1/books/handbook/users-introduction.html

- separates window manager and desktop environment

- tightens up the wording

Once edits are complete on this chapter, a separate whitespace fix will make igor happy.

Approved by:  gjb (mentor)
This commit is contained in:
Dru Lavigne 2013-10-04 17:54:01 +00:00
parent c41442ae34
commit a1a71f75c2
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=42828
1 changed files with 99 additions and 187 deletions

286
en_US.ISO8859-1/books/handbook/x11/chapter.xml
View file

@ -76,50 +76,34 @@
</sect1>
<sect1 id="x-understanding">
<title>Understanding X</title>
<para>Using X for the first time can be somewhat of a shock to
someone familiar with other graphical environments, such as
&microsoft.windows; or &macos;.</para>
<title>Terminology</title>
<para>While it is not necessary to understand all of the details
of various X components and how they interact, some basic
knowledge makes it possible to take advantage of X's
strengths.</para>
<sect2>
<title>Why X?</title>
<para>X is not the first window system written for &unix;, but
it is the most popular of them. X's original development team
had worked on another window system prior to writing X. That
system's name was <quote>W</quote> (for
<quote>Window</quote>). X was just the next letter in the
Roman alphabet.</para>
<para>X can be called <quote>X</quote>,
<quote>X Window System</quote>, <quote>X11</quote>, and a
number of other terms. You may find that using the term
<quote>X Windows</quote> to describe X11 can be offensive to
some people; for a bit more insight on this, see
&man.X.7;.</para>
</sect2>
<sect2>
<title>The X Client/Server Model</title>
of the various components in the X Window System and how they interact, some basic
knowledge of these components can be useful:</para>
<variablelist>
<varlistentry>
<term>X server</term>
<listitem>
<para>X was designed from the beginning to be network-centric,
and adopts a <quote>client-server</quote> model.</para>
<para>In the X model, the <quote>X server</quote> runs on the
and adopts a <quote>client-server</quote> model. In this model, the <quote>X server</quote> runs on the
computer that has the keyboard, monitor, and mouse attached.
The server's responsibility includes tasks such as managing
the display, handling input from the keyboard and mouse, and
other input or output devices (i.e., a <quote>tablet</quote>
can be used as an input device, and a video projector may be
an alternative output device). Each X application (such as
handling input or output from other devices such as a tablet
or a video projector.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>X client</term>
<listitem>
<para>Each X application, such as
<application>XTerm</application> or
<application>Firefox</application>) is a
<application>Firefox</application>, is a
<quote>client</quote>. A client sends messages to the server
such as
<quote>Please draw a window at these coordinates</quote>, and
@ -127,178 +111,106 @@
<quote>The user just clicked on the OK button</quote>.</para>
<para>In a home or small office environment, the X server and
the X clients commonly run on the same computer. However, it
is perfectly possible to run the X server on a less powerful
desktop computer, and run X applications (the clients) on,
say, the powerful and expensive machine that serves the
office. In this scenario the communication between the X
the X clients commonly run on the same computer. It
is also possible to run the X server on a less powerful
computer and to run the X applications on a more
powerful system.
In this scenario, the communication between the X
client and server takes place over the network.</para>
</listitem>
</varlistentry>
<para>This confuses some people, because the X terminology is
exactly backward to what they expect. They expect the
<quote>X server</quote> to be the big powerful machine down
the hall, and the <quote>X client</quote> to be the machine
on their desk.</para>
<varlistentry>
<term>window manager</term>
<para>It is important to remember that the X server is the
machine with the monitor and keyboard, and the X clients are
the programs that display the windows.</para>
<para>There is nothing in the protocol that forces the client
and server machines to be running the same operating system,
or even to be running on the same type of computer. It is
certainly possible to run an X server on &microsoft.windows;
or Apple's &macos;, and there are various free and commercial
applications available that do exactly that.</para>
</sect2>
<sect2>
<title>The Window Manager</title>
<para>The X design philosophy is much like the &unix; design
philosophy, <quote>tools, not policy</quote>. This means
that X does not try to dictate how a task is to be
accomplished. Instead, tools are provided to the user, and
it is the user's responsibility to decide how to use those
tools.</para>
<para>This philosophy extends to X not dictating what windows
<listitem>
<para>X does not dictate what windows
should look like on screen, how to move them around with the
mouse, what keystrokes should be used to move between windows
(i.e.,
<keycombo action="simul">
<keycap>Alt</keycap>
<keycap>Tab</keycap>
</keycombo>, in the case of &microsoft.windows;), what the
mouse, which keystrokes should be used to move between windows, what the
title bars on each window should look like, whether or not
they have close buttons on them, and so on.</para>
<para>Instead, X delegates this responsibility to an
application called a <quote>Window Manager</quote>. There
they have close buttons on them, and so on. Instead, X delegates this responsibility to a
separate window manager application. There
are <ulink
url="http://xwinman.org/">dozens of window managers</ulink>
available for X. Each of these window managers provides a
different look and feel; some of them support
<quote>virtual desktops</quote>; some of them allow customized
keystrokes to manage the desktop; some have a
<quote>Start</quote> button or similar device; some are
<quote>themeable</quote>, allowing a complete change of
look-and-feel by applying a new theme. Window managers are
available. Each window manager provides a
different look and feel: some support
virtual desktops, some allow customized
keystrokes to manage the desktop, some have a
<quote>Start</quote> button, and some are
themeable, allowing a complete change of the desktop's
look-and-feel. Window managers are
available in the <filename>x11-wm</filename> category of the
Ports Collection.</para>
<para>In addition, the <application>KDE</application> and
<application>GNOME</application> desktop environments both
have their own window managers which integrate with the
desktop.</para>
<para>Each window manager uses a different configuration
mechanism. Some expect configuration file written by hand while
others provide graphical tools for most configuration tasks.</para>
</listitem>
</varlistentry>
<para>Each window manager also has a different configuration
mechanism; some expect configuration file written by hand,
others feature GUI tools for most of the configuration tasks;
at least one (<application>Sawfish</application>) has a
configuration file written in a dialect of the Lisp
language.</para>
<varlistentry>
<term>desktop environment</term>
<note>
<title>Focus Policy</title>
<listitem>
<para>Some window managers, such as <application>KDE</application> and
<application>GNOME</application> are considered to be desktop environments
as they include an entire suite of applications for performing
common desktop tasks. These may include office suites, web
browsers, and games.</para>
</listitem>
</varlistentry>
<para>Another feature the window manager is responsible for is
the mouse <quote>focus policy</quote>. Every windowing
system needs some means of choosing a window to be actively
receiving keystrokes, and should visibly indicate which
window is active as well.</para>
<varlistentry>
<term>focus policy</term>
<para>A familiar focus policy is called
<quote>click-to-focus</quote>. This is the model utilized
by &microsoft.windows;, in which a window becomes active
upon receiving a mouse click.</para>
<listitem>
<para>The window manager is responsible for the
mouse focus policy. This policy provides
some means for choosing which window is actively
receiving keystrokes and it should also visibly indicate which
window is currently active.</para>
<para>X does not support any particular focus policy.
Instead, the window manager controls which window has the
focus at any one time. Different window managers will
support different focus methods. All of them support
click to focus, and the majority of them support several
others.</para>
<para>One focus policy is called
<quote>click-to-focus</quote>. In this model, a window becomes active
upon receiving a mouse click. In the
<quote>focus-follows-mouse</quote> policy, the window that is under the mouse pointer
has focus and the focus is changed by pointing at
another window. In the <quote>sloppy-focus</quote> model, if
the mouse is moved over the root window, no window has the focus and
any keystrokes are lost. With sloppy-focus, focus
is only changed when the cursor enters a new
window, and not when exiting the current
window. In the <quote>click-to-focus</quote> policy, the active window is selected by mouse click.
The window may then be raised and
appear in front of all other windows. All keystrokes
will now be directed to this window, even if the
cursor is moved to another window.</para>
<para>The most popular focus policies are:</para>
<variablelist>
<varlistentry>
<term>focus-follows-mouse</term>
<listitem>
<para>The window that is under the mouse pointer is
the window that has the focus. This may not
necessarily be the window that is on top of all the
other windows. The focus is changed by pointing at
another window, there is no need to click in it as
well.</para>
<para>Different window managers
support different focus models. All of them support
click-to-focus, and the majority of them also support other policies.
others. Consult the
documentation for the window manager to determine which
focus models are available.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>sloppy-focus</term>
<varlistentry>
<term>widgets</term>
<listitem>
<para>This policy is a small extension to
focus-follows-mouse. With focus-follows-mouse, if
the mouse is moved over the root window (or
background) then no window has the focus, and
keystrokes are simply lost. With sloppy-focus, focus
is only changed when the cursor enters a new
window, and not when exiting the current
window.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>click-to-focus</term>
<listitem>
<para>The active window is selected by mouse click.
The window may then be <quote>raised</quote>, and
appear in front of all other windows. All keystrokes
will now be directed to this window, even if the
cursor is moved to another window.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Many window managers support other policies, as well
as variations on these. Be sure to consult the
documentation for the window manager itself.</para>
</note>
</sect2>
<sect2>
<title>Widgets</title>
<para>The X approach of providing tools and not policy
extends to the widgets seen on screen in each
application.</para>
<para><quote>Widget</quote> is a term for all the items in
<listitem>
<para>Widget is a term for all of the items in
the user interface that can be clicked or manipulated in
some way; buttons, check boxes, radio buttons, icons, lists,
and so on. &microsoft.windows; calls these
<quote>controls</quote>.</para>
<para>&microsoft.windows; and Apple's &macos; both have a
very rigid widget policy. Application developers are
supposed to ensure that their applications share a common
look and feel. With X, it was not considered sensible to
mandate a particular graphical style, or set of widgets to
adhere to.</para>
<para>As a result, do not expect X applications to have a
common look and feel. There are several popular widget sets
and variations, including Qt, used by
<application>KDE</application>, and GTK+, used by the
<application>GNOME</application> project. In this respect,
there is some convergence in look-and-feel of the &unix;
desktop, which certainly makes things easier for the novice
user.</para>
</sect2>
some way. This includes buttons, check boxes, radio buttons, icons, and lists.
A widget toolkit is a set of widgets used to create
graphical applications. There are several popular widget toolkits, including Qt, used by
<application>KDE</application>, and GTK+, used by
<application>GNOME</application>. As a result, applications will have a
different look and feel, depending upon which widget toolkit
was used to create the application.</para>
</listitem>
</varlistentry>
</variablelist>
</sect1>
<sect1 id="x-install">