This chapter endeavours to give you background concepts you'll need to customise your X Window System environment. The focus is on information which is general to all X applications. It assumes you are familiar with some variety of UNIX editor, understand /bin/sh shell scripts and basic X Concepts. If you're not, have a look at the chapters on Vi, bash and introductory X elsewhere in this Manual.
From a user's point of view, the most important component of X is the graphics terminal you actually sit in front of. This is referred to as a Display. The piece of software controlling the Display is referred to as the Server.
In principle the Server is quite dumb; it is simply concerned with the actual process of drawing text and graphics onto the screen. The Server may have a machine dedicated to running it (correctly referred to as X Terminals), or may be running as a regular process on a workstation.
Actual X applications, like Mozilla, are referred to as Clients. Clients connect to a Server and send it drawing requests, which the Server translates into actual graphics on the Display. When the user clicks or types into a window, the Server will send events back to the Client which owns the window. Clients can connect to a Server on the same machine, or across the network to a Server on a completely different machine. In this way, the X Window System is network transparent; Clients need not be on the same machine as the Server19.1.
The term session is used to refer to the time period between logging onto an X Display and logging off it19.2. The program that displays the login box is called xdm. Nowadays you may also encounter kdm or gdm if you run the KDE or Gnome desktop environments. After it has verified your login and password, it will setup the appropriate shell environment variables and execute the commands in a session file.
A session file is simply a shell script, ie: a list of commands to execute in order. Normally the session file starts up all of your favorite X Clients. The default session file at the Faculty of IT looks something like:
#!/bin/sh xrdb /usr/lib/X11/X11/usr/Xresources unclutter & twm & sleep 1 dclock -geometry 256x80-10+10 & xcal & xvt -geometry 80x48+10-20 -name 'Login Shell' & xconsole -verbose -exitOnFail -daemon -geometry 400x70-10+130 xlogoff -geometry -10-20 csh -c /system/admin/register/Logout kill -9 0
The first line indicates that the file is a shell script which is to be executed by the Bourne shell (/bin/sh). The line:
xrdb /usr/lib/X11/X11/usr/Xresources
loads in the standard FIT X resources (See Resources later in this chapter). The lines:
unclutter & twm & sleep 1 dclock -geometry 256x80-10+10 & xcal & xvt -geometry 80x48+10-20 -name 'Login Shell' & xconsole -verbose -exitOnFail -daemon -geometry 400x70-10+130
all start up some initial X Clients19.3. Consult the appropriate manual page for descriptions of exactly what they do19.4. The important thing to note is that they are all started in the background, as indicated by the trailing ampersand19.5. Starting them in the background allows them to all execute concurrently.
At least one Client should be started in the foreground. In this case it's xlogoff. This is a Client which simply displays a box and exits when it's clicked on. Since it's in the foreground, /bin/sh will wait for it to exit before continuing. The line
csh -c /system/admin/register/Logout
is to clean up after Eiffel, removing all the large intermediate files it deposits everywhere, and
kill -9 0
is for your own benefit, killing off any stray processes.
If you have a .xsession file in your home directory xdm will use that instead of the default session file. A skeleton session file follows.19.6 The remaining section describes major pitfalls you should look out for.
#! /bin/sh # Start your favorite clients # like these xvt terminals. # The sleeping should speed things up should # by giving twm a chance to start up. (sleep 2; xvt &) (sleep 2; xvt &) # start up a window manager (twm) as the # session manager twm # clean up csh -c /system/admin/register/Logout kill -9 0
You session is over when the last command in your session file has been executed (in the standard session file it's the kill -9 0). At the end of your Session xdm resets the Server, killing off any Clients, and redisplays the login box. If everything was started in the background the end of the file would be reached almost immediately, and your Session would be over almost as soon as it began. As soon as your Clients had started up, the Server would be reset!
One solution to this is to put a wait command at the end of the session file, which waits for all the commands started in the background to exit, before continuing. This means to end the Session you have to exit (or kill off) all of the clients you start up in your session file. This is typically a pain, especially if your bus leaves in two minutes time.
A better idea is to always start the last client in the foreground, ala xlogoff. Clients used like this are referred to as session managers. The session manager is typically a terminal emulator (like xvt or xterm), a window manger (like twm) or sometimes a special client (like xlogoff).
If you do something silly in your .xsession, like starting all of your Clients in the foreground19.7, you may not be able to successfully start a session at all. However, don't panic. The Great Ones have anticipated our foolishness and have provided a back door: login as normal, but instead of pushing the return key after your password, press the F1 key. This will ignore your .xsession file completely and start up a single terminal window for you19.8. From this you can edit your .xsession file and correct the errors. Note that because a session file is just an ordinary shell script you can execute it like any other (by setting the execute permissions and typing its name). This is useful for testing session files, since any error messages will be displayed in the terminal window.
Normal UNIX programs do input and output through the terminal. X Windows Clients are simply UNIX programs which open a window on the X Server and use that instead. Graphical user interfaces are typically more intuitive than text based ones. You may like to compare the difference in output between bc and xcalc.
Most X Clients are configurable. At the bare minimum you should be able to specify foreground and background colours, fonts, etc. Clients which have been written using a toolkit based on the X Toolkit Intrinsics typically let you configure just about everything19.9.
Clients typically understand a number of command line arguments. At the bare minimum all X applications should understand the following command line arguments. A short discussion of their format follows.
All of these are discussed in vastly more detail in the X(1) manual page.
X allows your to refer to colors by names. The list of names it
understands is in
[4]/usr/lib/X11/rbg.txt (eg: DarkSlateGray.
You can also specify a RGB colour specification of the form:
rgb:red/blue/green
The components must be all one, two or three digit hexadecimal numbers (eg: red is f/0/0 or ff/00/00).
There are three major forms of geometry specifications:
x and y are X and Y offsets from the edges of the screen, and are in pixels. If the values are positive, it means the top-left corner of the window should be positioned that number of pixels from the top/left corner of the screen. Similarly, if they are negative, it means the bottom-right corner should be that number of pixels from the bottom-right corner of the screen. It is perfectly valid to have one value positive and the other negative.
w and h are width and height of the window, and can be in pixels or characters, depending on the application. Terminal windows and editors are typically characters.
The following examples should illustrate how to use geometry specifications:
| +50+300 |
The left side of the window is 50 pixels from the left side of the screen, and top side 300 pixels from the top of the screen. |
| -100-200 |
The right side of the window is 100 pixels from the right side of the screen, and the bottom side 200 pixels from the bottom of the screen. |
| +0+0 |
The top-left corner of the window should be in the top-left corner of the screen. |
| -0-0 |
The bottom-right corner of the window should be in the bottom-right corner of the screen. |
| -0+0 |
The top-right corner of the window should be in the top-right corner of the screen. |
| +0-0 |
The bottom-left corner of the window should be in the bottom-left corner of the screen. |
| 80x24 |
The window should be 80 pixels/characters wide and 24 pixels/characters high. |
| 115x60-316+0 |
The window should be 115 units wide, 60 units high and have the right side 316 pixels from the right edge of the screen, and it's flush against the top of the screen. |
You can use the xdpyinfo command to find out the dimensions (and all sorts of other useful information) of the Display. See the GEOMETRY SPECIFICATIONS section of the X(1) manual page for more information.
Normally the DISPLAY environment variable is used by the application to determine which Server it should connect to. This is set automatically when your X session is started. This can be overridden by the -display command line option. In both cases, the display is described by a string of the form:
hostname:displaynumber.screennumber
Since the Faculty of IT has no machines with more than one display or screen attached to them, the displaynum and screennum fields are both ``0''. You can omit screenum altogether if you like. See the DISPLAY NAMES section of the X(1) manual page for more information.
The Server maintains a database of fonts available to applications. You can browse the available fonts using the xfontsel command. A fontspec is a string which looks something like19.10:
-misc-fixed-medium-r-normal--13-100-100-100-c-70-iso8859-1
The ``-'' characters separate fields. You can put a ``*'' in any field meaning you don't care about the value of the field. For example, the following fontspec will probably refer to the same font as the above, except it doesn't care about the family or registry fields:
-misc-*-medium-r-normal--13-100-100-100-c-70-*-1
Note that since ``*'' has special meaning to most shells, if you are specifying a font on a command line you should place it in quotes. You can list the fonts which match a pattern using the xlsfonts command. The entire set of characters in a font can be displayed using xfd. It should be noted that the greater the number of fonts you use simultaneously, the more memory your session will require.
The FONT NAMES section of the X(1) has a more complete discussion of fonts, including scalable fonts.
Clients can also be customised via resources. To customise a
Client this way, you first need to figure out its class name. The
basic rule is to capitalise the first character of the command name,
or the first two characters if it begins with ``x''19.11. For example,
all of the xcalc Clients belong to the XCalc
class19.12.
A resource string specifies the value of an applications
resource. Resource strings which begin with a class name apply to
all Clients of that class. Thus the following will only apply to xterm's (and xvt, since it considers itself of the class XTerm):
If you don't have a class name, it will apply to all Clients.
The following sets the default background colour to MistyRose:
The ``*'' means that the value applies to all parts of the
application. You can provide more specific resource settings which
will override the more general ones by using ``.''. Eg:
will set the cursor for the bitmap program to be a
pirate19.13 for all of the window, except for the
drawing (bitmap) area, where it should use the left_ptr cursor.
There is a more comprehensive section on resources in the RESOURCES section of the X(1) manual page.
The X Server holds a database of resources. Resources placed in .Xresources in you home directory will be automatically loaded
into the Server before the session file is executed. You can load
additional resources, or override existing ones, by using the xrdb command. To load resources in an ad-hoc manner use something
like:
You can get xrdb to load an entire file of resources, ala:
When loading resources, xrdb first passes the text through the C
pre-processor /usr/lib/cpp. Directives to the cpp begin with hash
in the leftmost column, and will be documented in any good book on C and in the
cpp(1) manual page.
The xrdb -query command will print out a list of all the
resources currently loaded into the server.
Resources can also be loaded via an application defaults file. This
is a file with the same name as the application class, typically
located in:
It contains the default
values for resources. These values are overridden by entries in the
Server resource database. Looking at the application defaults is
useful for finding (some) of the resources you can change. For
example, the aXe application defaults file is in /usr/lib/X11/app-defaults/Axe.
You can supply your own application defaults in the same style as the
The appres command can be used to print out the Resource Database
and Application Default entries for a specific application class. For example,
the following will print the resources for the DClock class:
The editres program is particularly useful for browsing the list
of resources the application understands19.14.
After some experimentation you will probably come up with a couple of
different configurations for the one application19.15. You can
use class names to simplify the process of selecting a configuration.
Rather than having to give all the options on the command line, you
can just specify a resource name.
The following example loads resource entries for resource name cobol and gives it an appropriate font and icon. The last line starts an
example xterm.
Note that the xterm will revert to its original class name to
find its application defaults.
Applications written with Xt allow you to do all manner of
groovy things with translations. The most straight forward
translations let you bind X events, such as mouse clicks and key
presses, to actions. The following example binds the keypad keys on
Sun style keyboards to scroll the text window forwards and backwards.
Each line specifies an event sequence, in this case key strokes, and
the action that is to be performed when the application receives that
event sequence. Note that if #override is not specified all the
default translations are wiped out, which is bad, since most of them
are quite useful. The actions are typically documented in the
application manual page. For further examples of translations have a
look in the /usr/lib/X11/app-defaults directory. A convenient
way of figuring out which keys produce which events is the ev
command. The manual page and the application-defaults file should tell
you what actions can be invoked.
See the xterm(1) manual page for more information.
With the most important aspect of server configuration, the Resource Database,
already discussed, all that's left is ``user preferences''. The xset
program can be used to view and modify these.
Before you start changing things it's best to get a dump of
the current values, via:
The first thing you will probably want to change is the bell. Sun
terminals use the keyboard buzzer to create the bell sound (even the sparcs
which have an inbuilt speaker). This unfortunately means the settings for
bell volume and pitch controls do stuff all. Fortunately duration still
has an effect, so if you find the standard bell ringing as annoying as I
do, try something like:
Next, you'll probably want to speed up the mouse. The server will accelerate the mouse when it travels more than threshold pixels in a
short period of time. I use my mouse mostly for jumping between
windows19.16, so
I like the acceleration to be quite high, and the threshold low. In the
following, the mouse if sped up by four times after moving ten or more pixels.
Any values you set will only last for the current session. To make them
permanent put them in your .xsession file. See the xset(1) manual
page for more information.
The best source of information is of course the X manual pages.
Particular ones worth looking at are X(1) and xterm(1).
The MIT distribution comes with some documentation, which is probably
available at the Technical Support Desk. O'Reilly have a well regarded series of
books on X, but like most material on the subject tend to assume you're
an X programmer. Some of this series are available in the interface
room. The comp.windows.x groups have Frequently Asked Question
(FAQ) files available, which are usually available in the news.answers group.
Any similarity to Chris Keane's X section (from the 1991 Sun
User Guide) and the MIT X documentation is purely
coincidental.19.17
XTerm*savelines: 2000
XTerm*Title: "Terminal Window"
XTerm*IconName: Term
XTerm*IconPixmap: term.bm
XTerm*background: black
XTerm*foreground: white
XTerm*iconic: false
*background: MistyRose
Bitmap*cursor: pirate
Bitmap*bitmap.cursor: left_ptr
Server Resource Database
% echo 'Axe.server.geometry: 80x100+100' | xrdb -merge
% xrdb -merge .Xresources
Application Defaults
/usr/lib/X11/app-defaults
[4]/usr/lib/X11/app-default ones. This involves creating your
own app-defaults directory and adding the path to
XUSERFILESEARCHPATH. Doing so isn't recommended unless you have
huge amounts of application resources in your .Xresources file.
Browsing Resources
% appres DClock
Specifying Class Names
% cat >> ~/.Xresources
cobol*font: -*-clean-medium-r-*-*-15-*-*-*-c-*-*-*
cobol*boldfont: -*-clean-bold-r-*-*-15-*-*-*-c-*-*-*
cobol*icon: sufferingMisery.bm
cobol*iconName: "Misery"
cobol*title: "Life is Misery"
^D
% xrdb -merge ~/.Xresources
% xterm -name cobol
Translations
% cat >> ~/.Xresources
XTerm.vt100*Translations: \
#override \n\
The Server
% xset q
% xset b 0 0 2
% xset m 4 10
Further Reading
Disclaimer