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

Add probably 50% of a section introducing some key X concepts that the

Browse source 
reader is unlikely to be familiar with from any exposure to window systems
they may already have.

This probably needs many index entries scattered through it.
This commit is contained in:
Nik Clayton 2001-08-11 01:17:28 +00:00
parent 205cf1b49a
commit 1ea482405f
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=10299
1 changed files with 242 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

243
en_US.ISO8859-1/books/handbook/x11/chapter.sgml
View file

@ -1,7 +1,7 @@
<!--
The FreeBSD Documentation Project
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/x11/chapter.sgml,v 1.39 2001/08/09 23:42:35 chern Exp $
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/x11/chapter.sgml,v 1.40 2001/08/10 22:58:17 chern Exp $
-->
<chapter id="x11">
@ -21,6 +21,10 @@
<para>After reading this chapter you will know:</para>
<itemizedlist>
<listitem><para>How to install and configure XFree86.</para></listitem>
<listitem>
<para>The various components of the X window system, and how they
interoperate</para>
</listitem>
<listitem><para>How to install and use different window managers</para></listitem>
<listitem><para>How to use TrueType fonts in XFree86</para></listitem>
<listitem><para>How to setup your system for graphical logins (XDM).</para></listitem>
@ -299,6 +303,243 @@ EndSection</programlisting>
</sect2>
</sect1>
<sect1 id="x-understanding">
<title>Understanding X</title>
<para>If you are familiar with using windowing systems that ship with
other operating systems, such as Microsoft Windows, or MacOS, then you
may find your first introduction to X to be something of a culture
shock.</para>
<para>Today, as Unix desktop environments such as KDE and GNOME become
more prevalent it is less necessary to understand all the
behind-the-scenes interaction between the various X components, or what
those components actually are. However, one of X's strengths is its
underlying design, which lends a great deal of flexibility, and makes it
possible to do things with X that are impossible with other, more rigid,
systems.</para>
<sect2>
<title>Why X?</title>
<para>X is not the first window system written for Unix, but it is the
most popular. X's original development team had worked on another
window system before writing X. That system's name was
<quote>W</quote> (for <quote>Window</quote>, obviously). X is just
the next letter in the Roman alphabet.</para>
<para>X can be referred to variously as <quote>X</quote>, <quote>X
Window System</quote>, <quote>X11</quote>, and other terms.
<quote>X Windows</quote> is to be avoided wherever possible; see
&man.X.1; for more information.</para>
</sect2>
<sect2>
<title>The X Client/Server Model</title>
<para>X was designed from the beginning to be network-centric, and
adopts a <quote>client-server</quote> model. In the X model, the
<quote>X server</quote> runs on the computer that has the keyboard,
monitor, and mouse attached. The server is responsible for managing
the display, handling input from the keyboard and mouse, and so on.
Each X application (such as <application>XTerm</application>, or
<application>Netscape</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 the server sends back
messages such as <quote>The user just clicked on your OK
button</quote>.</para>
<para>If you are using FreeBSD in a home or small office environment
where you only have one computer then you will be running the X
server and the X clients on the same computer. However, if you have
many machines running FreeBSD it is perfectly possible to run the X
server on the computer by your desk (which might be quite a low
specification machine) and run your X applications (the clients) on
the powerful expensive server that serves your office. In this
scenario the communication between the X client and server takes
place over the network.</para>
<para>This confuses a lot of 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>
<para>As long as you remember that the X server is the machine with
the monitor and keyboard, and the X clients are the programs that
display the windows you will not get confused.</para>
<para>There is an interesting side-effect to this design. There is
nothing in the 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 perfectly feasible 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>
<para>The X server that ships with FreeBSD is called
<application>XFree86</application>, and is available for free, under a
license very similar to the FreeBSD license. Commercial X servers for
FreeBSD are also available, should you want one.</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>. By this we mean that X (and Unix)
does not try to dictate to the end user how they should accomplish
whatever task they are trying to solve. Instead, they aim to provide
the user tools to do the job, 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 should
look like on screen, how you move them around with your mouse, what
keystrokes you should use to move between windows (i.e.,
<keycombo action="simul">
<keycap>Alt</keycap>
<keycap>Tab</keycap>
</keycombo>, if you are familiar with 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
the <quote>Window Manager</quote>. There are dozens of window
managers available for X; <application>AfterStep</application>,
<application>Enlightenment</application>,
<application>ctwm</application>, <application>ftwm</application>,
<application>sawfish</application>, <application>twm</application>,
<application>WindowMaker</application> and more. Each of these
window managers provides a different look and feel; some of them
support <quote>virtual desktops</quote; some of them allow you to
completely customise the keystrokes you can use to manage your
desktop; some have a <quote>Start</quote> button, or similar device;
some are <quote>themeable</quote>, allowing you to completely change
the look-and-feel of your desktop by applying a new theme. These
window managers, and many more, are available in the
<filename>x11-wm</filename> category of the Ports Collection.</para>
<para>In addition, the KDE and GNOME desktop environments both have
their own window managers which integrate tightly with the desktop,
although both of them allow you to replace the default window manager
with your own choice.</para>
<para>Each window manager also has a different configuration mechanism;
some expect you to write a configuration file by hand; others feature
GUI tools for carrying most of the configuration tasks; at least one
(<application>sawfish</application>) has a configuration file written
in a dialect of the Lisp language, which is very powerful (if you are
in to that sort of thing).</para>
<para>As you can imagine, this flexibility comes with a price. It can
be very difficult for documents such as this one to guide you through
choosing and configuring a window manager because the available choice
is so wide.</para>
<note>
<title>Focus Policy</title>
<para>Another feature the window manager is responsible for is the
mouse <quote>focus policy</quote>. Each windowing system, be it X,
Microsoft Windows, or some other has an abstraction called the
<quote>focus</quote>, and at any one time only one window can have
the focus. The window that has the focus is the window that will
receive all your keypresses and mouse clicks.</para>
<para>You are probably familiar with a focus policy commonly called
<quote>click-to-focus</quote>. This means that you must click on
the window you want to have the focus. The window may then come to
the top of the stack, and all your keypresses will now be directed
to this window, even if you move the mouse outside the window. To
give the focus to another window you must first click in it.</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>The two other most popular focus policies are:</para>
<variablelist>
<varlistentry>
<term>focus-follows-mouse</term>
<listitem>
<para>With this policy, 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. You can change the focus by pointing at another
window, there is no need to click in it as well.</para>
<para>After getting used to this policy it can be very
disorientating going back to another system that uses
click-to-focus.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>sloppy-focus</term>
<listitem>
<para>This policy is a small extension to focus-follows-mouse.
With focus-follows-mouse, if you move the mouse over the
background (or desktop, also called the root window) then no
window has the focus, and your keypresses go nowhere.</para>
<para>If you use sloppy-focus and move the mouse pointer on the
root window then the last window that had the focus will keep
it.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Your window manager will almost certainly support other
policies, and variations on these two, so make sure you read the
documentation it is supplied with.</para>
</note>
</sect2>
<sect2>
<title>Widgets</title>
<para>The X approach of providing tools and not policy extends to the
widgets that you see on screen in each application.</para>
<para><quote>Widget</quote> is a GUI term for all the items in the user
interface that you can click on and manipulate in some way; buttons,
checkboxes, radio buttons, icons, lists, and so on. Microsoft Windows
Developer documentation calls these things
<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. X was designed long before
either of these windowing systems, when research into GUI systems was
in its infancy, and it was felt that it would not be sensible to
mandate a particular graphical style, or set of widgets that have to
be adhered to. If you examine the evolution of the Windows or MacOS
GUI over the past ten years you will see many examples of how the
interfaces have been altered over time to reflect new thinking in the
art of Human/Computer Interaction.</para>
<para>The upshot of this is that you can not expect X applications to
have a common look and feel. There are several popular widget sets
(and variations), including the original Athena widget set (developed
at MIT), Motif (on which the widget set in Microsoft Windows was
modeled, all bevelled edges and three shades of grey), OpenLook, and
others.</para>
<para>Most newer X applications today will use a modern-looking widget
set, probably either Qt, used by KDE, or GTK, used by the GNOME
project. In this respect we are beginning to see a convergence in
look-and-feel on the Unix desktop, which certainly makes things easier
for the novice user. However, the sudden rise in popularity of
<quote>theming</quote>, where window managers make it possible to
dramatically personally your desktop and alter the look and feel of
the widgets risks confusing the issue once more.</para>
</sect2>
</sect1>
<sect1 id="x-fonts">
<sect1info>
<authorgroup>