Using X for the first time can be somewhat of a shock to someone familiar with other
graphical environments, such as Microsoft® Windows® or Mac OS®.
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.
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 “W” (for
“Window”). X was just the next letter in the Roman alphabet.
X can be called “X”, “X Window System”, “X11”, and
a number of other terms. You may find that using the term “X Windows” to
describe X11 can be offensive to some people; for a bit more insight on this, see
X(7).
X was designed from the beginning to be network-centric, and adopts a
“client-server” model.
In the X model, the “X server” 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 “tablet” can be used as an input device, and a video
projector may be an alternative output device). Each X application (such as XTerm, or Netscape®) is a “client”. A client sends
messages to the server such as “Please draw a window at these coordinates”,
and the server sends back messages such as “The user just clicked on the OK
button”.
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 client and server takes place over the network.
This confuses some people, because the X terminology is exactly backward to what they
expect. They expect the “X server” to be the big powerful machine down the
hall, and the “X client” to be the machine on their desk.
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.
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
Mac OS, and there are various free and commercial
applications available that do exactly that.
The X design philosophy is much like the UNIX design
philosophy, “tools, not policy”. 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.
This philosophy extends to X not dictating 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., Alt+Tab, in the case of Microsoft Windows), what the
title bars on each window should look like, whether or not they have close buttons on
them, and so on.
Instead, X delegates this responsibility to an application called a “Window
Manager”. There are dozens of window managers available for X: AfterStep, Blackbox, ctwm, Enlightenment, fvwm, Sawfish, twm, Window Maker, and more. Each of
these window managers provides a different look and feel; some of them support
“virtual desktops”; some of them allow customized keystrokes to manage the
desktop; some have a “Start” button or similar device; some are
“themeable”, allowing a complete change of look-and-feel by applying a new
theme. These window managers, and many more, are available in the x11-wm category of the Ports Collection.
In addition, the KDE and GNOME
desktop environments both have their own window managers which integrate with the
desktop.
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 (Sawfish) has a
configuration file written in a dialect of the Lisp language.
Focus Policy: Another feature the window manager is responsible for is the
mouse “focus policy”. 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.
A familiar focus policy is called “click-to-focus”. This is the model
utilized by Microsoft Windows, in which a window becomes active upon receiving a mouse
click.
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.
The most popular focus policies are:
- focus-follows-mouse
-
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.
- sloppy-focus
-
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.
- click-to-focus
-
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.
Many window managers support other policies, as well as variations on these. Be sure
to consult the documentation for the window manager itself.
The X approach of providing tools and not policy extends to the widgets seen on screen
in each application.
“Widget” is a term for all 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 “controls”.
Microsoft Windows
and Apple's Mac OS 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.
As a result, do 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 from
MIT, Motif® (on which the
widget set in Microsoft Windows was modeled, all bevelled edges and three shades of
grey), OpenLook, and others.
Most newer X applications today will use a modern-looking widget set, either Qt, used
by KDE, or GTK+, used by the GNOME
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.
