|
Introduction to the X Window System - original September 1992, revised September 1998 - Warren Jessop (whj@cs) |
|
 CSE Support |
Printer Friendly Version (PDF) |
CSE Home |
About Us |
Search |
Contact Info |
xrsh
twm
xdm login window.
twm operations do not work.
Xrsh does not work the way you think it ought to.
The X Window System is a network-transparent window system that was designed at MIT.
Network-transparency means you can use a graphics workstation to interact with X application programs that run either locally on that workstation or on other computers attached to the network.
Window system means X allows you to build and use programs that follow a "desktop metaphor" pioneered by Xerox in the 70's, made popular by the Apple Macintosh in the 80's, and dominated by Microsoft Windows in the 90's. Features of that metaphor include displaying and being able to manipulate multiple overlapping (usually rectangular) windows, each of which performs some function such as displaying a clock or managing files. In the case of X all the windows are arranged in strict hierarchies. At the top of each hierarchy is a root window (the background), which covers each of the display screens, and which is in turn partially or completely covered by "child" windows. Thus each window, except for root windows, has a "parent" window. A child window may have its own children, thus a single application program can create an arbitrarily deep hierarchy of windows on each screen.
In the parlance of X: a display consists of a set of one or more screens, a keyboard, and a pointing device---usually a mouse; an X server is a program that runs on the local workstation and controls the display; and an X client is a program that communicates with an X server---sending commands to create, change, or delete windows and requesting input from keyboard and mouse. Many X clients are available on the CSE Lab computers, including terminal emulators, text editors, drawing tools, viewers for text and pictures in various formats, WYSIWYG text/graphics layout tools, spreadsheets, mail and news readers, clocks, calendars, demos and miscellaneous utilities. Some of the more important X clients are discussed below.
An X server does not enforce a particular "look-and-feel" (appearance and behavior) to the windows it creates; it only provides a mechanism for creating and manipulating windows. The basic look-and-feel of the metaphorical desktop is provided by that most important of X client programs, the window manager. You cannot effectively use X without a window manager.
The window manager supported by the CSE Lab is called twm. It is
supplied with the free distribution of X software from MIT. Other
window managers you might encounter when using X are mwm, the
Motif Window Manager, and olwm, the Open Look Window Manager.
Motif and Open Look are two look-and-feel specifications that dictate
not only how the window manager operates, but also the look-and-feel
of X clients. It may look strange, but it is possible to run clients
supporting one look-and-feel with a window manager supporting another
because there are elaborate rules that all well-behaved X clients must
follow.(1) Since twm abides by the rules, you should
be able to use it with any well-behaved X application.
Twm and all the other window managers allow you to perform the same
basic functions:
Another important X client is the display manager, xdm. This is
a client that is normally started by the system. Between login
sessions on most workstations, when no user is displaying windows on
the screen(s) of a display, xdm puts up a window that invites a
user to start a login session. The invitation window displayed may be
one of two types:
When you log in for the very first time, the initial clients started
for you by default are twm and xterm, a DEC VT102 terminal
emulator. The xterm window appears in the upper left. In the
upper right is an icon manager window (more about this later).
This configuration is created by a default session file,
`/usr/X11R5/lib/X11/xdm/Xsession'. You may customize the initial
configuration by creating a file called `.xsession' in your home
directory. More about customization later.
On UNIX workstations, an additional client, xconsole, may be
started and maintained by xdm. Xconsole's function is to
display messages from the workstation's operating system.
When the initial xterm window is selected (by moving the pointer
inside its border) you can enter UNIX commands to csh, the
command interpreter. To end your login session, use the csh
logout command in this xterm window. After a delay, the
login or host menu window will once again appear.
Twm's appearance and behavior is controlled by a startup file,
`.twmrc', in your home directory. If that file does not exist,
twm uses a default startup file,
`/usr/X11R5/lib/X11/twm/system.twmrc'. If you are satisfied with the
default behavior, you don't need to worry about what to put in your
own `.twmrc' file.
Features of the default appearance and behavior are:
xterm window on the host you are logged into.
When you start an X client, twm first displays only a window
outline for you to position (using the mouse). Once you have it
positioned, clicking on a mouse button causes the window to appear.
emacs or
xman.
twm operations, e.g refresh the screen
There are many X applications you might find useful. Start by trying
out xman, the UNIX man page browsing utility. It has an
excellent help page, and you will be introduced to the look-and-feel of
"Athena widget" scrollbars.(2)
Using xman you can view the man pages that cover general aspects
of X, e.g. X, Xconsortium, Xstandards, and Xsecurity. The
X man page lists the "core" X clients supplied by MIT. In
addition, the CSE Lab supports some other X clients and utilities, whose
man pages you can consult for further information, e.g.: emacs,
ghostview, xcalendar, xcolors, xdvi, xfig, xloadimage, xlock, xplot,
xproof, xrn, xrsh, xtex, xv and xwd2ps.
There are (at least) three types of workstations that can run X servers and function as X displays: UNIX workstations (such as DECstations or SPARCstations), NT workstations, and X terminals. To a UNIX or NT workstation an X server is just another process. An X terminal differs in that it runs a stripped-down operating system designed to support the needs of just one program: an X server. Some of the more sophisticated X terminals can also run a few X clients, such as a built-in window manager and an xterm window that allows you to log into other computers on the network.
Strictly speaking, you cannot log into an X terminal. You can only
log into the host computer that runs the xdm client that puts up
the login window on the X terminal. Most of the X terminals in the
department "home in" on one host; both that host name and the X
terminal's display host name appear in the login window. A few X
terminals offer you a choice of hosts to log into.
When you log into an NT workstation in any of the CSL labs, you should
see on the desktop "Reflection X" icons, labeled `fiji',
`tahiti', etc. These will start (or wake up) a WRQ "Reflection"
X server on the workstation. When you select one of these an xdm
login window is presented for the selected host, just like on the
real X terminals.
A few Suns do not run xdm so that users may choose either the
MIT X server or the Sun xnews server. After logging in, use
either xinit for MIT X or openwin for Sun's OpenWindows
3.0.
Every X display has a unique name for each screen, of the form:
[hostname]:displaynumber[.screennumber]
Every X client must know the display and screen it is expected to use.
Almost all clients have a command line option called -display to
allow explicit specification. Using -display is usually not
necessary, however, since under most circumstances an environment
variable, DISPLAY, is automatically set to the display name.
If hostname is missing, as in `:0', the display is local,
and both server and client must be running on the same host.
Otherwise, in our environment, hostname is the Domain Name of
the machine that runs the X server. Every workstation has a unique
Domain Name, e.g. goat.cs.washington.edu, or, when using X
between computers in the Computer Science domain, goat whould
suffice. Displaynumber is almost always 0, since one host
usually serves only one display. Screennumber defaults to 0,
the first screen. A few workstations in the building have two
physical screens, numbered 0 and 1.
xrsh
Suppose you are logged in to host barb using X terminal
guppy, and you want to use an X application that can be run only on
another host on the network, say a drawing tool called xdp to be
run on host hammahamma. This is a job for xrsh. If you can
remotely execute ordinary commands on hammahamma from barb using
rsh(3), then in a barb xterm
window you could enter:
xrsh hammahamma xdp |
Xrsh takes care of all the details of running xdp on
hammahamma. It makes sure the DISPLAY environment variable is set to
guppy:0.0 in the remote shell, and it automatically handles access
control, as discussed in the next section.
Given that an evil X client running on any host on the local net can try to send commands to and gather information from the X server running at your workstation, how can you be protected against snooping and spoofing by others? X provides several levels of control:
xhost command can restrict access
to only a named list of hosts on the network. See the xhost man
page for details. Older X clients and servers, particularly those for
which we have no source code, may provide only xhost access
control.
When you log in, xdm associates a randomly generated magic
cookie with the display name, informs the X server, and puts the
(magic cookie, display name) pair in a file called `.Xauthority'
in your home directory. `.Xauthority' is readable only by
processes owned by you. A client looks up the X display's magic
cookie, if any, in your `.Xauthority' file and sends it to the X
server in its first (connection setup) message.
There are three ways to have the cookies match:
xdm is identical to the
one read by the X client, e.g. your X client and xdm are running
on the same host, or your home directory is automounted on both
client and xdm hosts.
xauth extract - $d | rsh hammahamma "xauth remove $d; xauth merge -" |
xauth man page for more details. By default, this is
the technique xrsh uses to ensure a remote client may use a
display.
xhost overrides the magic cookie authorization
protocol, e.g. xhost barb means any client on barb can access the
display, regardless of magic cookies.
To an X server a font is an array of characters (or, more
generally, arbitrary images or "glyphs"). Each font has overall
attributes such as the total number of characters and whether strings
are drawn left-to-right or right-to-left; moreover, each
individual character has additional metric information to determine
proper spacing.
X clients must be able to deal with X server implementations having different file systems, naming conventions, and font libraries. But they must also be able to determine in a uniform manner what fonts are available on a server so that intelligent alternative fonts can be chosen if the first choices are not available. This is the reason for the X Logical Font Description (XLFD) conventions.(4)
An XLFD is a compound name having fields separated by hyphens, e.g.
-adobe-courier-bold-o-normal--10-100-75-75-m-60-iso8859-1 |
Some of the more interesting fields are:
xdpyinfo command.)
xterm and emacs can only use
fixed-width fonts.
In addition to the full font name, X servers support font
aliases, e.g. 9x15 is an alias for
-misc-fixed-medium-r-normal--15-140-75-75-c-90-iso8859-1 |
The xlsfonts command lists fonts and aliases your server knows
about. The X server supports wildcarding in font names, e.g.
xlsfonts -fn '-*-courier-medium-*'
will list all the Courier family medium weight fonts the server knows.
A good tool to select and view fonts is xfontsel.
The X server knows where to find font files via a directory list called
a "font path" (just as the shell knows about commands via a command
path). To see the font path, use the xset command: `xset q'.
The xset command also allows you to change the font path.
See man pages for X and xset for more information.
There are several ways to customize X application (client) programs:
xterm window, use the `-sb' option. Not all X clients
allow you to customize everything with the command line; xterm
is an exception.
xterm has three pop-up menus (hold down the control key
and press the left, middle, or right mouse buttons). As with command
options, not all X clients provide the means to customize in this
way.
A resource is a (name,value) pair. A resource name is generally a
hierarchically ordered list, with elements corresponding to major
structures within an application. The man page of each X application
describes all its resource names and possible values.
The elements of a resource name can be separated by periods or, if
wildcard matching is desired, by asterisks. The first element of a
resource name can apply either to a class of clients or to instances
of clients that have a matching name (specified by the `-name'
option). By convention, class names begin with capitals, e.g.
"XTerm," and instance names begin with lower case, e.g. "myXterm,"
an instance of which could be created by xterm -name myXterm.
For example, to specify scrollbars on all applications belonging to class "XTerm," put the following line in your `.Xresources' file:
XTerm*scrollBar: True |
XTerm.VT100.scrollBar.
Wild cards are very powerful. For example,
if there were other classes of clients that allowed scrollbars to be
specified with the name "scrollBar," and you wanted scrollbars on
all of them, this line will do the trick:
*scrollBar: True |
XTerm*geometry: 80x56+0+0 |
XTerm.VT100.geometry and
XTerm.SimpleMenu.geometry, and so xterm's popup
menus, whose dimensions are measured in pixels, not characters, will
be too small to use.
For the complete story of resources, look in the "RESOURCES" section
of the X man page.
Some window systems (e.g. Microsoft Windows or the OS2 Workplace
Shell) make it easy for you to save the arrangement of windows and
icons on your screen so that the next time you use the window system
things are put back the way they were. Some look-and-feel
specifications that have an X implementation, such as Open Look,
require this capability. Using MIT X and twm, however, you must
create a shell command file in your home directory called
`.xsession' that invokes an initial set of X
clients.
Here is a very simple `.xsession' file with comments:
#! /bin/csh # Sample .xsession file # Load your X resource settings into the X server. if ( -r $HOME/.Xresources ) xrdb -load $HOME/.Xresources # Start the window manager twm & # Put a clock in the lower left corner xclock -geometry 100x100+0-0 & # Put a big xterm in the middle of the screen with a nice font. # (Name the font using an alias). xterm -geometry 80x66+370-1 -fn lucidasanstypewriter-12 & # Create a login xterm window (with the -ls option). # To end the session, enter "logout" in this window. exec xterm -geometry +0+0 -fn 6x10 -title login -ls |
Notes:
chmod +x .xsession.
csh script
rather than a sh script. Csh will read your `.cshrc'
file, thus your environment variables will be set properly.
exec command.
twm
As described in the 20+ pages of its man "page," twm, the
supported window manager, can be customized in many ways. All the
customization is contained in one file, `.twmrc'; unlike some
other window managers, twm does not use X resources. If
`.twmrc' does not exist in your home directory,
`/usr/X11R5/lib/X11/twm/system.twmrc' is used by default. We suggest
you start with the default file, i.e. copy it to your home directory.
It is well commented. There is no need to log out and back in to try
changes: use the twm restart function available on the "TWM
Operations" menu.
You can customize to some extent the behavior of the server.
xsetroot to set the root (background) window to a specified
pattern or color, or to set the root cursor to something other than
"X."
xset to set preferences such as bell volume, mouse
acceleration, and auto repeat.
xmodmap to change the keyboard mapping, for example, to
change the function of the BackSpace key to Delete, enter
xmodmap -e "keysym BackSpace = Delete" |
xdm login window. Check that the DISPLAY environment variable is set correctly. Remember, if you are using an X terminal the host name of the display is not the name of the host you are logged into.
Usually a trio of messages, e.g.:
Xlib: connection to "stehekin:0.0" refused by server
Xlib: Client is not authorized to connect to server
Error: Can't open display: stehekin:0
|
xhost command to
force the server to accept clients. See man pages for xauth and
xhost.
twm operations do not work.
Make sure `.xsession' has a call to twm. Check your
`.twmrc' file.
Xrsh does not work the way you think it ought to.
Read the "COMMON PROBLEMS" section of the xrsh man page.
| Jump to: | .
A C D L O R T W X |
|---|
| Jump to: | .
A C D L O R T W X |
|---|
These rules are embodied in a document called the ICCCM: Inter-Client Communications Conventions Manual, Version 1.1, MIT X Consortium Standard, X Version 11, Release 5, David Rosenthal, MIT, 1991
Most of the X clients originally supplied by MIT make use of the ancient "Athena widget" programming toolkit, also supplied by MIT.
You must have a barb.cs.washington.edu entry in your hammahamma `.rhosts' file to do this.
X Logical Font Description Conventions, Version 1.4, MIT X Consortium Standard, X Version 11, Release 5, Jim Flowers, DEC, 1989