Despite the extent it has spread in the UNIX world, the X Windows
System is not a UNIX product. The X Window System, affectionately
called X, was developed by the Massachusetts Institute of Technology
and runs on a wide range of computers. There are even MS-Windows
The first version was developed at MIT in 1984. Several versions have
been developed since, with the most current version, X version 11
(X11), being first released in 1987. X11 has been adopted as the
industry standard windowing system, with the support of a consortium
of major computer industry companies such as DEC, HP, SUN and IBM.
The Basics of X
An X session is usually composed of several windows, each running a
separate program, or client. Like a program on any other system,
programs running under X vary in functionality. Some interact
completely with the user like the xterm
terminal emulator. Others simply display output on the screen like
the xload system monitor.
The background window is referred to as the root window. Applications
windows, or clients, are displayed on top of the root window. Like
UNIX processes, these windows are grouped together, or related, in a
family hierarchy. Like init is the great-grandmother of all
processes, the root window is the great-grandmother of all windows.
Clients displayed on the root window are children of the root window
and the root window is their parent. This hierarchy actually extends
to different parts of a window. For example, menus are often
considered children of the parent window as they inherit
characteristics, but also can be configured and react independently
of the parent window.
X consists of two sides: a server side and a client side. The
basic functionality is similar to the way all client-server models
work in that the X server has certain resources that it provides to
the client. It is a common misconception that the server and clients
are on the same machine. because X is integrated with the TCP/IP
stacks, requests can come from any client and can be requested of any
server. In addition, because X is not a program but more a protocol,
machines can communicate with completely different architectures. For
example, a Digital OSF/1 server can provide services to both a SCO
and an AIX client, as well as either of the others providing services
to the OSF/1 machine. Just like other network applications, a single
machine can be both client and server.
The server acts as the interface between the client programs and the
physical hardware. When you input data, either through the keyboard
or pointer, the server accepts that input and is responsible for
passing it along to the client. This information is passed to the
client as events. Pressing a key or moving the pointer cause
an event, to which the client may react. Often that reaction is in
the form of changing the display on the screen. For example, a client
receives the event that a particular menu was click on. It responds
by requesting the server to display the pull-down menu. The server
then passes the information on to the hardware, which shows the
pull-down menu. As a screen, it gives it to the server, which then
passes to the hardware. As a result of this separation of
functionality, one client could display information on more than one
In order to start anything, an X server needs to be running
somewhere. Despite that fact that you can access servers anywhere on
the network, the most common configuration is where the server is
running on the same machine as the client The two most common ways on
both ODT and OpenServer are to either have scologin enabled or to use
the startx shell script.
The scologin program is
conceptually very similar to the way a normal login works. Although
the interface is graphical, you are prompted to input your name and
password. Incorrect values generate and error message and correct one
get you logged into the system, just like a normal login. Also like a
normal login an environment is set-up for you. If enabled, scologin
will be available for you every time the system boots.
The next common way is through the startx
shell script. This reads the .startxrc
file in your home directory and treats it in the same way as your
shell would treat the .cshrc
and .kshrc files. Here is
where your initial clients are started, such as terminal emulator,
and the window manager If you don't have a .startxrc
file in your home directory, then startx
will read the system default file /usr/lib/X11/sys.startxrc.
In reality, the X server is started by the xinit
program. However, both scologin and startx
start xinit for you.
Contrary to popular belief it is neither the X server nor the
clients that are responsible for the appearance of the windows on the
screen as we understand them. Instead, this falls to a window
"manager." SCO provides two window managers: OSF/Motif
Window Manager (mwm) and the Panning Motif Windows Manager (pmwm).
Pmwm is actually an enhanced version of mwm, which provides virtual
windows. Both mwm and pmwm are actually clients themselves and
provide the window appearance such as their locations on the screen,
borders, menus and the appropriate actions when the mouse is used or
keys are pressed.
What you can do to each part of a window is important in
understanding the basic concepts of X. A click is used to
active a button. The is done by quickly pressing down and releasing
one of the mouse buttons. Since there is only one mouse button on
many systems, the mouse button used to click is usually button number
one. On right handed mice, this is the left button. A double-click is
where the button is clicked twice in succession. The maximum time
allowed between clicks in order to be recognized as a double-click
can be configured using the scomouse
utility. To drag an object you select that object by placing the
pointer somewhere on that object and pressing down and holding the
first mouse button. In many cases, such as xterm or scoterm, you must
click on the title bar. You then see the outline of that window,
which you can move to its new location. You can also select the
window by clicking on Move in the Window Menu. You drop an object
onto another by dragging that object over another and then releasing
the mouse button. This only works in appropriate circumstances. For
example, dropping a document on the printer icon to print it.
If you have multiple clients on the screen, the exists in a kind of
stack. Although they may be positioned so that no part of any window
overlaps an other window, they are still considered to be in a stack.
That is, there is one window that is considered to be on top (usually
the active one) and the others are at different levels underneath.
You can bring any window to the top of the stack simply by clicking
on it. If, however, the windows overlap so that one or more windows
are obscured, you can cycle through the windows in either direction.
Let's assume we have three clients running. They are, in order from
top to bottom: A, B and C. By pressing ALT-TAB we cycle down the
stack. That is, B is now on top, followed by C, with A now on the
bottom. Pressing ALT-TAB again, we have C on top, then A and B is now
on the bottom. If we press ALT-TAB third time, A is once again on
top, followed by B, then C. This effectively takes the top of the
stack and moves it to the bottom or we are selecting the next
client. If we press SHIFT-ALT-TAB, the process is reversed. The
bottom of the stack is brought up to the top or we are selecting the
Description of the various parts of a window
It can also be said that you, the user, manage the windows. You
determine the size and location of the window, as well as determine
which is the active window. Changing the size of the window is done
in several different ways. My moving the pointer, you can grab
any corner of the window by pressing and holding down the left mouse
button. You can then move that corner in any directory, thus changing
both the horizontal and vertical sizes of the window. You can also
grab an edge and change either the horizontal or vertical edge,
depending on what edge you grab. In addition, you can choose the Size
option from the window menu and then move the pointer to the edge or
corner you want to use to resize with. This time you do not hold down
the left mouse button.
There are also two buttons in the upper right hand corner of the
window. The outer one is the maximize button. When you click on it,
the window will fill the screen (it maximizes). When you click on it
again, it returns to its previous size. Not the default, but the size
it was when you clicked the maximize button. The other is the iconify
button. This turns the window into a miniature version of its former
self. This is a "representation" of that window. These
little images are referred to as icons. Double-clicking on the icon
returns it to the size it was. Here again, not the default
When you choose which window is active you set the focus.
There are two types of focus policies used: explicit and pointer. If
set to explicit focus, you must click explicitly somewhere within the
window to set the focus. If set to pointer focus, the focus is set
when the pointer enters a window. The default is explicit focus, and
I suggest you leave it until you are very familiar with moving around
windows or have a compelling reason to change it. The problem with
pointer focus is that you could be typing away in one window,
accidentally push the mouse so the pointer is in another window. Now,
all of a sudden, the new window is accepting input. On slower
machines, the opposite effect might happen. You intentionally move
the pointer to a new window and start typing. However, it takes a
moment for the focus to "catch up" with you and therefore
the input is sent to the previous window.
Common to every windowing system (at least every one I have ever
seen) is the concept of a menu. Like a menu in a restaurant, a menu
in X presents you a list of choices. Windows in X come in two types:
pull-down and pop-up. Pull-down menus are almost universally
associated with a particular location on the window. When you click
on that location, a menu appears to drop down from that location. In
a sense, you are pulling down that menu. By default, each window has
Window Menu located in the upper left corner. This is a small square,
with a horizontal bar running through it. Some people describe it as
looking like a filing cabinet drawer with a handle. When you click on
the Window Menu, you are give options that are related to the window
itself. These include moving the window, resizing it, or changing its
position in the windows "stack" (raising or lowering it).
Pop-up menus are usually not associated with any particular location
on the window. These menus "pop-up" from the current cursor
position. An example of a pop-up menu is the Root Menu that pops up
anytime you click on an exposed area of the root window.
Above I mentioned that it was the window manager that determined the
"look and feel" of an application. However, this is not
entirely true. Although what we see presented is a function of the
window manager, the underlying routines used to represent a button or
a scrollbar, can be different. Most of the SCO provided clients use a
set of routines called the X Toolkit (Xt). This is actually two
libraries that are used to create the interface components (buttons,
menus, etc). These are referred to as "widgets." The two
libraries are the X Toolkit Intrinsics and the Athena Widget set
Keep in mind that X does not provide a graphical user interface
(GUI). X is simply the windowing mechanism, but some other component
provides the GUI. In order to produce such a GUI, the Open Software
Foundation (OSF) developed the Motif Toolkit, which is based on the X
Toolkit Intrinsics and a set of widgets developed by DEC and HP. This
was originally designed to emulate the look-and-feel of the
IBM/Microsoft Presentation Manager used in OS/2.
On ODT and OpenServer you will find both Motif and standard X
applications. Motif applications are those that use the Motif
Toolkit. These all have a common look-and-feel. One standard X
application is the clipboard. If you run it along with some other
application such as SCOEdit, you will notice some distinct
difference. The most dramatic is the overall appearance. Motif based
applications appear three dimensional, whereas standard X
applications look "flat."
When the clients connect to the server, one of the key pieces of
information it needs is the display name. The display is of the form:
The hostname identifies the name of the machine that the display is
physically connected to. The most common form of hostname is simply
the node name as more than likely the server is in the same network.
However, it is possible to use a fully qualified domain or even an IP
address for the hostname.
Unless you have some special hardware, you probably have only one
physical display per server. However, each display is given a number
starting at 0. If you only have one, then you are always accessing
hostname:0. The screen number is only used in cases where a single
keyboard and mouse are associated with multiple monitors. Like
displays, screens are counted starting at 0. Since multiple screens
are far less common than multiple displays, you can leave of the
screen number when specifying the display. Generally, the default
display is stored in the DISPLAY variable, which is then used by
default. However, many X clients have a -display
option, with which you can specify the display.
The important next issue is the concept of geometry. One of
the advantages of a system like X is the ability to not only move
windows around the screen, but to change their size and shape as
well. Rather than using the window manager to change the shape of the
window, we can specify the shape and size when the application is
started. This is done by specifying the client's geometry.
The geometry is represented by four characteristics: width, height,
distance from left or right and the distance from the top or bottom.
These are referenced by width, height, xoff and yoff, respectively.
Depending on the application, the height and width are measured in
either pixels or characters, whereas the xoff and yoff values are
measured only in pixels. Both xoff and yoff are measured in
relationship to the screen. The general for of the geometry
Here the + sign in front of the xoff and yoff, indicate a distance
from the left and top edges of the screen, respectively. By changing
the + to a -, we change the offset to be from the right and bottom
instead of left and top. For example, if you wanted to start the
analog clock 30 pixels to the right of the upper left hand corner,
the command would look like this:
-geometry 90x90+30+0 &
(It's a good idea to run all clients in the background, otherwise you
don't get your prompt back until the client terminates.) Now, if we
wanted to start the clock 30 pixels to the left of the upper right
hand corner, the command would look like this:
-geometry 90x90-30+0 &
Now, if we wanted to start the clock 30 pixels to the left of the
lower right hand corner, the command would look like this:
-geometry 90x90-30-0 &
The four corners are thus mapped like this:
You can also specify negative offsets that would then start the
client outside of the respective edge of the screen. For example, if
we change the above command to look like this:
-geometry 90x90--30+0 &
It will start the client so that right edge of the clock is 30 pixels
outside of the right edge of the screen. (Be careful not to have
spaces in there) This does not mean that the entire clock is outside
of the right edge of the screen. This is a misconception that many
people have (including myself at first). On many systems, there is
something magical about the upper left hand corner of the client.
Offsets from the edge of the screen are in relationship to this
magical corner. This is not so with X.
A +xoff value is the distance of the left edge of the client
from the left edge of the screen. A -xoff value is the distance of
the right edge of the client from the right edge of the
screen. This also means that a +yoff value is the distance of the top
of the client to the top of the screen and -yoff is the distance from
the bottom of the client to the bottom screen.
Note that the geometry is specified in pairs. So, if you
specify the height, you must also specify the width. Also if you
specify the x-offset, you must also specify the y-offset. However,
you don't have to specify the offsets if you only want to specify the
size. Therefore we could start the clock like this:
-geometry 90x90 &
This gives me a 90x90 clock at the default location. If we only want
the offset and to take the default size, it might look like this:
-geometry +100+42 &
The thing that bothers me about this clock is that it is pretty
boring. The colors are drab and it really doesn't have any life to
it. The nice thing is that we can change the colors. With the analog
clock, there are several different things we can change. If we wanted
the background color to be cornflowerblue, we would enter the
-bg cornflowerblue &
This creates an analog clock with the default size at the default
location with a background of cornflowerblue. However, it still looks
boring. I want a foreground of red. So, let's run the command like
-bg cornflowerblue -fg red &
Now it's beginning to have a little life to it. However, having both
hands red is still not good enough. I want the hour hand red, but the
minute hand white, and the jewel at the top of the clock I want
yellow. The command would then look like this:
-bg cornflowerblue -hour red -minute white -jewel yellow &
That's not all. There is a couple more options that we can
use. However, these are listed in the oclock(X) man-page so you can
take a look there if you want. Other clients have different option,
since some of them don't make sense with an analog clock. For
example, the digital clock (dclock) has an option to specify the font
(-fn). Since there are no characters on the analog clock, an option
to change the font wouldn't make sense.
If we wanted we could have also include the geometry along with the
colors. This ends up giving us a command that is almost too long for
the screen. Even now, it is a long command, that takes a long time to
type in and you can easily make mistakes. One solution would be to
write up everything in a shell script and start that script instead
of typing everything on the command line.
The nice thing is we don't have to. X provides a mechanism to
change the appearance and sometimes the behavior of a client to fit
our personal preferences. This is the concept of a resource. Up to
now, we have specified the resource from the command line, such as
foreground color and geometry. However, there are resource files that
we can edit to change the default characteristics of a given client.
Resource files for most applications are found in
/usr/lib/X11/app-defaults, The general form of the resource
The application is usually the name of the program you are starting
with the first letter capitalized. Note the word "usually."
I don't know how many times I've tried to change a resource and not
have it work, only to find out that this one application's name is
written small. In the case of the files in
there is no appname necessary as there is one file for each client
and X knows what client is meant when it reads these files. If set, X
will search the path specified by the XFILESEARCHPATH
variable for the resource information.
Unless you want to change the system defaults, I suggest leaving
these files alone. Instead you can create a user or machine specific
resource file. Normally, this is $HOME/.Xdefaults-hostname,
where "hostname" is the name of the host these resource
specifications apply to. If this .Xdefaults
file is to apply to the local host, you can leave off the hostname.
If you want to specify an alternative file, you can use the
These resources are organized into classes. This allows you to set
groups of individual resources all at once. Individual resources are
referred to as an instance. By convention the class name begins with
an upper case letter and the instance begins with a lower case. We
can generally say that a resource (both class and instance) is named
for the aspect of appearance that it controls. For example, there is
a class called Foreground, which sets the foreground color. An
instance of the Foreground class would be specified with a lowercase
F: foreground. Keep in mind that different parts of the clients are
affected by the class Foreground, such as the text color, cursor
color, and pointer color.
Basically all applications have the following resources. In each case
the class name has an initial capital. Examples of this are:
window background color
width in pixels of
the window border
window border color
The distinction between classes and instances is very useful if we
want to set several resources at once. For example, if we define the
foreground color for all aspects of the scoterm, the resource
definition would look like this:
This would be equivalent to:
This means that the foreground color of text, cursor and pointer are
all blue. If we then defined the pointerColor instance to be
something else, only it changes. For example, if we made the
color is now red, although all the others remain blue.
Although the asterisk is perhaps the most commonly used delimiters,
it's not the only one. The asterisk delimiter is used to indicate a
loose binding. This is where there can be several layers in
the object hierarchy. It's easy to think of the asterisk as having
the same function as on the command line, that is, as a wild card.
Here, the asterisk represents 0 or more intermediate layers between
the root object and the resource we are defining.
If there are no intermediate layers between the objects, this
referred to as a tight binding. If we wanted is we could
specify the binding with the asterisk, since it means 0 or more
intermediate levels. However, the symbol used to explicitly specify a
tight binding is a dot (.). Since I know that the level just above
the pointerColor in the hierarchy is 'ansi,' I can make the
specification like this:
However, since the loose binding specifier(*) can be used any place,
but the tight binding specifier (.) only when appropriate, it is
easier to always use the loose binding specifier.
Both the resource specifications and binding can bring up some
conflicts. In the example above, we said to use blue for every
foreground color related to the client "ScoTerm." We also
said to use red for the foregound color of pointer. Now this seems
like a conflict, which it is, however in this case the instance of
the pointerColor took precedence over the class of Foreground.
Consider these lines from an .Xdefaults file:
We first define the Foreground class to be blue. Next, we define the
instance of the pointerColor to be red. Both of these are done with
loose bindings. We then define the instance of the pointerColor for
an ansi terminal to be green. Since tight bindings have precedence
over loose bindings the pointer is green.
Taking this one set further, we change the class specification so it
contains a tight binding. However, we leave the instance
specification a loose binding. So, we end up with these two lines:
In this case, there is a tightly bound class specification that is
followed by a loosely bound instance specification. When we start the
scoterm, the pointer is blue, not red. In general, we can say that
the more specific a specification is, the greater the precedence.
There are a limited number of options that we can use from the
command line, although there are many more resources that we might
want to change. In order to accommodate a large number of resource
without increasing the number of options, there is the -xrm option.
For example, if we wanted to change the tty modes of scoterm
(what the characters are for erase, delete, quit, etc) we could do
this using the -xrm option and specifying and instance of the
TtyModes class. For example, to change the interrupt key from the
default of DEL to CTRL-C, the command would look like this:
scoterm -xrm 'ScoTerm*ttyModes: intr ^C ' &
Keep in mind that this resource specification is only valid
for this one scoterm that we are starting here. If we wanted it to be
valid for all scoterms, we would either change the default in
or define the resource in the .Xdefaults
Although you may be satisfied with the default colors that X gives
you, I am sure that eventually you will want you make some changes.
In previous sections I talked about how you can change the color of X
clients either from the command line or changing the appropriate
resource. The only problem with that is you might not like the colors
that SCO offers.
You might be asking, "Why doesn't SCO just give me a list with
every possible color?" Well, you would need to have that list in
a file somewhere. If you did, you would have a list that was well
over 20Mb! The reason that would happen is because of the way SCO
How Colors Are Represented
Each color is represented by one byte for each of the three colors:
red, green, and blue. This scheme is referred to as RGB for these
three colors. Each byte can have one of 256 values that represent the
intensity of each color. In other words, the value represents how
much of each color is to be included. If all three colors have the
value 255, this is pure white. If each color has the value 0, you
file contains names of colors and often times variations in that
name. This is usually the case when the name of the color actually
consists of two words. For example: Antique White. In such a case,
you would also find the color antiquewhite. Each entry contains the
RGB values and the name of the color. For example, the antique white
entry would look like this:
250 235 215 antiquewhite
This means that the intensity of red in this color is 250/255 of full
intesity. The intesity of green is 235/255 and the intenisty of blue
is 215/255. What this really means is how much enegry is sent to each
phospor. For details on what phospors are and what part they play in
displaying an image see the section on monitors in chapter 12.
If you are specifying the color as a resource (either from the
command line or a resource file), you specify the color as a
hexadecimal value. The key thing to note is that you must specify the
value for each color, even if it is 0. Because the hexadecimal values
range from 0000-FFFF, you have many more possible combinations of
colors. When you do specify colors in this way, the hex string you
use must be preceeded by a pound-sign (#).
If you don't want to specify all four hexidemical digits, you
do not have to. However, all three colors need to be represented with
the same number of digits. This is because the system would not be
able to tell what value goes with what settings. If we look at an
example, this will be clearer.
Let's assume we want to set the intensity of red to F, the intensity
of green to 4, and the intesity of blue to 2. We might then have a
resource specification that looked like this:
What if we wanted the intesity of green to be 45, instead of 4. The
resource specification might look like this:
So what is it? Do we have red at F4, green at 5 and blue at 2? Or do
we have red at F, green at 4 and blue at 52? The only way to
keep things straight is if there are the same number of digits for
Remember that not all video systems are created equal. You may not
get the same color on your system as someone else, even if you use
the exact same hex values.
A key concept when dealing with colors and X is the idea of a color
palette. A palette is a set of 8 colors that defines the
primary portions of your windows. The characteristics are described
in Table 0.1.
Each X client you start displays the colors it finds in the current
palette. The colors used are configured by palette resource
variables. When displaying the X client, the X server replaces the
variable with the actual colors defined in the current palette. Color
variables are assigned the names described in Table 0.1.
Background color of
Background color of
all windows. This usually includes, text, menus, buttons,
Top shadow color.
This helps to give the window a 3D appearance.
Background color of
the active window
Foreground color of
the active window
Active top shadow
Clor of the top
shadow on the frame of the active window
Color of the
Desktop background, the for scrollbar and sliderbar troughs and
icon box background, if used
Color of a button
when it is pressed
Table 0.1 Color Characteristics
The system default palettes are located in
There are over a dozens palettes available ranging from Chocolate
(lots of browns) to Moonscape (lots of grays). You can add palettes
to these defaults by using scocolor, but scocolor will do it's best
to keep you from changing the default palettes. If you select any one
of the palettes from in /usr/lib/X11/sco/ScoColor/palettes,
then the "Delete Palette" button is disabled. Additionally,
if you double click any of the buttons indicating you want to change
the current color, you are prompted to input the name of a new
If you really want to you can edit the
/usr/lib/X11/sco/ScoColor/palettes file, but I would recommend
adding more palettes. If you use scocolor, then the palettes are
added to the file $HOME/.odtprefs/ascii/palettes.
If you are the system administrator and want to add a palette to the
system defaults, you create a palette that ends up in
You then add this to the end of the system palettes file. Afterwards,
this palette cannot be changed or deleted.
The primary tool for changing colors the the X-client scocolor.
The file that is used to list the names of the files along with the
intensity is /usr/lib/X11/rgb.txt.
This is an ASCII file that you can easily edit if you know what
changes you want to make.
If you add a palette or want to change one that you previously added
ypu can do this in scocolor. By clicking one of the current colors,
you can change the value of color. You have a choice of either a
color name or specifying the intesity using slide bars. If you want
to chose a color name and move the slide bar to give a slightly
diffent flavor to the color you can. The values that are stored in
the palettes file with by
the RGB values and not the color names.
In addition to using the RGB color model, scocolor can also use the
Hue/Satuaration/Value (HSV) model. I find the RGB much each to work
with as it is clearer to me what is being represented. The SCO doc
maintains that the HSV system is more intuitive, but I disagree. In
addition, the colors are stored using the RGB values anyway.
If you want to change the names of colors or add new ones, this is
done through the /usr/lib/X11/rgb.txt.
However, just changing the colors is not enough. Accessing a text
file is not the most efficient means of loading colors. Therfore, the
system uses a color database, which is "compiled" using the
rgb command. To compile the existing rgb.txt
file, change directories to /usr/lib/X11
rgb < rgb.txt
If you want to examin the existing color database, this can be done
with the command /usr/bin/X11/showrgb.
Since it is fairly long, you might want to consider piping it through
more or pg.
Note that the rgb.txt file also contains the SCO default colors
(scoBackground, scoHighlight, etc). So, if you want to change these,
then change the rgb.txt
Although not applicable to every client, fonts play a major role in
many applications. Defined as a set of characters for displaying text
and symbols, fonts share a common appearance in terms of size,
boldness, and other physical characteristics. Fonts themselves can be
grouped together into font families. Additionally, font families are
grouped by resolutions (dots-per-inch - DPI) into directories. So
named, because they were initially stored together in the same
directory in the filesystem. Each directory contains a database that
the server uses to translate font names into data that the server
uses to display the characters on the screen.
If the X client has a font menu like MS-Windows or Macintosh, life
would be easy when in came to fonts. Instead, we need to choose the
font as we are starting the application. If we were tired of the
boring font use by default on scoterms, we could choose something a
little fancier. Perhaps one that look like cursive. For example, we
could start sco term like this:
At first, this appears rather intimidating. There are over 700 fonts
on an OpenServer system and learning them all is a pain. More than
that, it is a waste of time. There are two utilities that make like
easier for you: xlsfont
and xfontsel. The
xlsfont utility simply
lists all the available fonts, with their complete name as we see
above. The xfontsel is a
real X clientthat allows us to pick and choose a font to based on
different criteria. What those criteria are is helpful in
understanding more about fonts.
Characteristics of the font name
The foundry is the font's developer. Here we have bitstream,
which as one would guess is from the company Bitstream, the same
people who develop so many fonts for MS-Windows. The font family
(here charter) is a convenient way of organizing the fonts by certain
The weight of a font can be thought of as its thickness. Common
weights are medium and bold. The slant, as you might guess is the
change in orientation of the character from the vertical. A roman
slant is upright, italic is tilted, but the characters are given a
slightly different shape to make them more esthetically pleasing and
oblique are just tilted with no changes to their shape. Here we have
an italic slant.
The set width is a general description of the average width. Common
set widths are normal, condensed and double-width. The size of the
font on the screen is determined by several aspects of the font name.
These characteristics are the pixels, points and both vertical and
horizontal DPI. Because the appearance on your screen is dependent on
your monitor as well as what fonts you choose, it's safe to gauge the
font size by the points. This is an old printer's measurement that
represents 1/72 on an inch. Here we have 120 tenths of a pitch,
therefore the size of each character is 1/6 of an inch.
One important characteristic is the font spacing. This determines
whether the font is proportional or monospaced. A
proportional font is one where the width of each character is
different. Although this looks good on paper or in a word processor,
it is not really suited for applications like terminal emulators.
Better for such applications is the monospaced font, where every
character takes up the same space.
The character set is basically another way of saying what letters are
represented. In this example and most others in ODT and OpenServer,
this field will be iso8859-1. This represents the ISO Latin 1
character set, which is a superset of the standard ASCII character
set. In addition to American English characters, iso8859-1contains
the special characters used in most European languages.
So now that we know what goes into font name, we can easily come up
with the right font. Well, maybe. Fortunately, we don't have to. We
can use wildcard for the parts of the font that we either don't think
are important or want to guess at. Anyone of the specifications can
be wildcarded and the system will do its best to find a match. By "do
its best" I mean that there can and will be cases where multiple
fonts match the specification. A rather simple example would be:
scoterm -fn '-bitstream-charter*'
On OpenServer, there are 60 matches. So, which one does the system
choose? Easy enough: the first one it finds. Unless you are more
specific, or know that the first one found is the one you want, you
might not get the font you want. Fonts are sorted in alphabetical
order, and since bold comes before medium, we get the bold version of
this font instead on the medium.
Why did we enclose the font name here inside of single-quotes,
although we didn't in the first example? Remember that the shell
expands everything into tokens before it passes things off to the
command. If we didn't use the single-quotes, the shell would try to
expand it and we get a message indicating the system cannot find that
Life is even simpler than that. We don't need remember any long drawn
out font names or try 20 different combinations to find the one we
want. We can take advantage of the fact that the system understands
font aliases. These are stored in the fonts directories in the file
fonts.alias. These are ASCII files with the alias in the first column
and the font name in the second column.
There are two things to keep mind. First, although you can edit these
files and make changes, the system will not recognize the new alias
unless you reset the font path with the xset command. This is simply
Next, unless you are absolutely positive about what fonts each user
is using and how they are being referenced, it is not a good idea to
remove aliases. If you remove an alias that some client is expecting,
the results are unpredictable.
If you always want to use a particular font with a particular
application, we don't need to always specify the -fn option when
starting the client Since the font is just another resource, we can
instead make the change to our resource definition file. An example
in our .Xdefaults file might look like this:
If you looked though the directory files, you won't find a font
simply named ibm10x20. This is actually an alias. However, If we
wanted to specify the full name of the font, we could have like this:
Also, just like specifying the front from the command line, we can
use wild cards to specify the "we-don't-cares."
The directories where the fonts are found by the server by
means of the font path. This is the XFONTS
variable, which defaults to
/usr/lib/X11/fonts, but can be changed using the xset command.
Because it is the server that is displaying the information on the
screen, the font path is on the server, not on the client machine.
Therefore it is important to ensure that the server is able to
display a particular font before changing it for any given client.
There are five sub-directories under /usr/lib/X11/fonts
varying in size and appearance.
The font database in contained in the fonts.dir file in each
directory. This is used when you select a font, the system knows what
file to read to be able to show the proper characters on the screen.
The font.dir files are ASCII files with the name of the font file in
the first column and the font name in the second column. When the
system is installed, the mkfontdir
reads the font files found in the font path and creates the fonts.dir
files. You can use mkfontdir
yourself, but the details of fonts creation and management goes
beyond the scope of this book.
Rather than requiring every machine on the network to have a full
compliment of fonts, there is something called a font server
Like a file server providing files across the network, a font server
provides fonts across the network. Just like files, if the font you
want is not available by the server, but is locally, there is no
problem. You can access it as well.
The font server is not started by default, but can be started in one
of several different ways. The first is from the command line, simply
Although this might be good for testing purposes, it is more
efficient to have the fort server start up every time the system goes
into multi-user mode. As will many of the different aspects of the
systems this is accomplished through a script in the /etc/rc2.d
directory. However, there is no script there by default. Obviously,
you could write the script yourself, but you ought to let the system
do it for you. This is done with:
Interestingly enough, this makes a link to itself in both /etc/rc2.d
When the scripts in /etc/rc2.d
are started they are given start
as an argument, which (since the script is linked) is the same as
starting it from the command line as above. It's just that the system
does that automatically for us.
Starting the font server from the command line is not recommended for
everyday use. In order to be able to use the fonts provided by the
font server you need to tell your X session about it. The best place
to do this is inside of your $HOME/.startxrc
file. Although the system administrator (you?) can change the
file, so everyone using the default gets to use it, you need to
remember those people that have already their own .startxrc file.
Before any clients are started, you use the xset command to specify
where the font server is. The general syntax is:
The server is the name of the machine on which the font server is
running, and port is the TCP broadcast port, which is 7000 by
default. For example, to access the font server on the machine
siemau, the command would be:
Or, if you want to use local fonts as well, the line might look like
The font server's configuration file is /usr/lib/X11/fs/config.
Here you can limit what fonts will be made available through the font
server. This is done by changing the catalogue entry and specifying
the fullpaths to the directories with the appropriate fonts. For
example, if you only wanted to have access to the 100 dpi fonts, the
line might look like this:
To make the changes take effect, either stop and restart the font
server or use the /etc/fontserv
command to re-read the configuration file and the flush the cached
Like nameservers in TCP/IP getting name information from other
nameservers, you can have font server get fonts from other font
servers. This is also done with the catalogue entry. For example, if
I wanted to make the local 100dpi fonts available as well as the
from the remote host scoburg, the entry might look like this:
Assuming that scoburg has their font server configured to use port
7000. Changing the port is also accomplished by changing the
file. On a line by itself, add a line specifying the appropriate
port. For example, if we wanted to change it to 7042, the entry would
look like this:
Once the change has made, the font server needs to be stopped and
restarted. If any other machines were using this server, they need to
be told that it is now set for port 7042.
You can use the -cf option when starting the fontserver to specify an
alternate configuration file. Reconfigure any X servers that use the
font server. NOTE: Exercise care when referencing other font servers.
Font server connections place a heavy demand on network resources and
bandwidth. Also, be careful not to let the number of references to
other font servers become so large that your system font server
The Window Manager
Because the window manager is an important aspect of X, we need to
cover it in some more details. As I mentioned earlier, OpenServer
provides two window managers mwm and pmwm. The panner version is
available as a separate product for ODT. Because the underlying
concepts are the same, we're going to talk about them first. Later,
there will be a separate section dealing with the issues related to
the panner. To make things easier, I will refer to the window manager
simply as mwm.
As I mentioned before, mwm is just another client. As such it has a
default file: /usr/lib/X11/app-default/Mwm
(Pmwm for the panning version).The following sections describe the
basic default behavior of windows, icons, the icon box, input focus,
and window stacking. The appearance and behavior of the window
manager can be altered by changing the configuration of specific
By default there are several accelerator keys that perform
various functions. These functions can also be reached through the
window menu. Any windows managed by mwm with have these keys. These
are explicitly defined and can be changed by modifying the
appropriate resource (Which we'll get to in a minute). These keys
Moves the window to bottom of the stack
Restores the window
to its previous size
Allows the window
to be moved with keys or the mouse
Allows the window
to be resized
The window manager is also responsible for managing icons. As I
mentioned earlier, icons are small graphic representations of
clients. Iconifying (turning into an icon) a client is a good way of
reducing the space take up by clients that are currently not being
used. Although the panner allows you to move clients from one virtual
screen to another, icons are a good way of being able to instantly
access a particular client. The icon box is enabled using the
*useIconBox resource. This is Boolean value, so enabling it through
the .Xdefaults file might
look like this:
A nice thing about the icon box is that it represents all running
clients and not just the ones that have been iconified. This makes
finding the client you want easy, since you double-click on its icon
in the icon box and it is immediately made the active window and
brought to the front.
If you click on the icon once, the icon menu pops up. This is
actually the same menu as the window menu. However, certain functions
are disabled (grayed out). For example, since the window is already
at its minimized size, the minimize option is disabled. However, you
can still move the icon. In this case, restoring returns the window
to it's previous size. It is often said that the window is "opened."
By double-clicking on the icon, it is restored to its previous size.
If you have a lot of icons, using the icon box is a good way of
managing them. The icon box is simply another client,which manages
the icon images. It can be moved and resized, even iconified. If
there are more icons in the icon box that can be shown in the box,
scroll bars will appear. An icon within the icon box can be restore
just like an icon when it's not in the icon box.
The icon box has a different window menu than the other clients.
Although it does have entries to move, resize and restore the icon
box itself, there are other entries that sort the icons.
One of the strong points of both window managers is the ability to
configure it to our tastes. Up to now we have basically been talking
about the appearance of mwm. What is really fun is to modify its
behavior. One way to accomplished is through the resource description
file. It contains descriptions of resources that are easily defined
in the resource files. This includes such things as the behavior when
buttons are pressed and the individual entries in each menu.
The default resource description file is /usr/lib/X11/system.mwmrc
Here again, unless you want to institute system wide changes, I
recommend copying the appropriate file into the user's home
directory. It then has the name $HOME/.mwmrc
or $HOME/.pmwmrc. Here is
where your default menus and default bindings are defined. When you
click on the root window, the root menu pops up. This is defined in
the .mwmrc or .pmwmrc
file and is very easy to modify to your personal tastes and
There are three types of resources that can be described here:
buttons, keys and menus. It is said that window manager functions are
bound to button or key press events. The relationship between
the button or key press is called a binding.
Since the resource description file is an ASCII text file, we can
easily edit it to make the changes we want. The format of each type
of resource is slightly different, but in each case, the fields are
separated by white spaces. Any text from an unquoted pound-sign (#)
to then end of the line is considered a comment. Therefore, if any
description needs to contain the pound-sign it must be quoted. Single
characters can be "quoted" by escaping them (using the
back-slash). Any line containing an exclamation mark as the first
character is also treated as a comment.
When an event occurs (button or key pressed, or menu item selected),
a particular window manager function is called. In general, we can
say that the functions have the following syntax:
There are dozens of functions that you can call, relating to
everything from resizing the particular window or icon, to shuffle
the order, moving, and all the other things we talked about. All of
these are detailed in the
so I don't feel a need to cover them all. However, I will discuss
some of the more common one as I describe the syntax of the resource
label in each line is the symbol that will appear in the menu pane
for that entry, here SCOTerm. Labels containing spaces or tabs, need
to be enclosed within double-quotes. For example "UNIX Window."
Symbol can be a text string or it can be bitmap. This allows you to
assign icons to the menu entries instead of textBitmap file names are
preceded by an at-sign (@). The entry then might look like this:
When you specify a bitmap, mwm defaults to reading
If the bitmap you want is not there, you must specify the full path.
If mwm cannot find the file, it displays the entry as if it were
text. If in the above example, the file was actually called,
terminal.xbm, I would not see the terminal bitmap, but rather the
text string "@terminal," at-sign included.
A mnemonic is a single character that is used to activate the menu
option when the menu pane is visible. Contrast this to accelerator
keys that are active whenever that particular window has the focus.
When a mnemonic is defined it is preceded by an underline. Then, the
first character in the menu label that matches the character
specified will also be underlined. When the menu pane is displayed,
you can activate that window function simply by pressing the key
specified. Here we have _U. When displayed, the U in UNIX will be
If the function called is the no-operation function (f.nop), the
function is invalid or doesn't apply in the given context, then the
label is grayed out (disabled). If a function is specified that isn't
one of the supported functions, then it is interpreted by mwm as
The accelerator key syntax is:
Where [modifiers] can be things like Ctrl for the control key, Alt
for the alt key and Shift for the shift key. Here we have said the
accelerator key combination is CTRL-U. So, when I want to have a new
UNIX window I just press CTRL-U.
Note that in contrast to button presses, key bindings to window
manager functions are just for the key presses. Key releases
have no meaning in this context. Also the modifiers are exclusive.
That means that no other modifier key can be pressed. Since I
specified just CTRL-U and not SHIFT-CTRL-U, pressing SHIFT-CTRL-U
would have no effect (unless I had defined it to something already).
Choosing this combination taught be two things. First, any
accelerator that is defined for the root menu is valid no matter what
other window is active. Since I had included this definition within
the RootMenu section of my resource file, anytime I wanted a new unix
window I just pressed CTRL-U. Much of this text was typed using 'vi'
from within a scoterm window. I realized that this was not a good
accelerator key when I tried to move up a couple of screens in 'vi'.
Remember from the section on 'vi', CTRL-U is used to move up screens.
Since it is the X server that gets the keystrokes and passes them to
them to the client, 'vi' never saw them. Instead I had five new
scoterms. Needless to say, I changed that accelerator key rather
The next type of resource that I want to talk is also commonly
modified. These are menu resources. The two functions related to menu
are f.post_wmenu, which causes the windows menu to drop down and
f.menu, which creates a pull-out or cascading menu. It is said that
it creates a new window pane. This is similar to a pull-down
menu, except that the menu starts to the right of the item that
called it. For example, if one menu item calls the f.menu function, a
new menu will appear to the right of that menu. If bound to a button
press, the menu will appear to the right of the current pointer
When the f.menu function is called, mwm searches for the menu label
within the resource file. The menu definition has the follow syntax.
[mnemonic] [accelerator_key] function
[mnemonic] [accelerator_key] function
[mnemonic] [accelerator_key] function
example might look like this:
"Admin Menu" _A
When you click on the Menu entry labeled "Admin Menu" a
pull-out menu appears with the content that appear between the curly
brackets. Each entry within the sub-menu is just like any other any
contain f.exec, f.menu or any other functions. If you want, you can
have several layers of sub-menus, but I have never found the need to
have more than three. Even that was getting a little unsightly.
Each button binding has the following syntax:
button context function
The button field, describes the state that the button enters for the
event to take place . For example, and entry that said <Btn1Click>
would mean that button 1 was clicked. Or <Btn2Down> means that
button 2 must be down.
The context is where the button must be for the button action to have
an effect. The contexts are defined as follows:
a window frame icon
an icon window
a window title
title area of the window frame
the window frame border
the border area (not including the title bar)
the application window, (not including the window frame)
Contents can be OR'ed together to enable that behavior at different
times. For example:
This says that anytime the pointer is over a window frame or an icon
and button 2 is pressed, the window menu should be posted.
The button bindings are grouped together similar to the way menu is.
In general, it looks like this:
In order for these button bindings to take effect, you have to set
the buttonBindings resource value to the group_name. For example, If
I had a button bindings group called JimButtonBindings, the
definition would look like this:
Because there are no default button bindings, per se, you must
include all the bindings you within the bindings sections. This is
done within the .Xdefaults
file. Examples of other button states are:
Btn1Down Press Button 1
Press and Release Button 1
Release Button 2
Double-Click Button 3
Aside from limiting where on the window a particular function is
applicable, there are also limitations as to what kind of windows the
function applies. For example, if the window has been iconified,
minimizing does nothing as the window is already minimized. If the
window is already its normal size, the restore function has no
effect. Basically what happens is that if the functioned invoked has
no meaning in the particular context, it is treated as a f.nop. See
the mwm(XC) for a list of what functions apply in what contexts.
First introduced as an extension product to ODT 3.0, the SCO
panner is perhaps one of the most significant improvements to X since
its inception. Basically, the Panner is an enhanced version of the
OSF/Motif Window Manager (mwm) which is the standard window manager
on ODT. It is rather trite to say that all it does is provide virtual
screens fro you to work in. Although this is true, it is comparable
to saying X only gives you windowing capabilities.
One of the problems I, as well as many other users face is that we
often do not have the luxury of large monitors. To have more than a
handful of clients running, we usually end up with them being either
overlapped or sometimes completely hidden. Often to avoid clutter, we
will iconify the less frequently clients to make room for others.
However, this cures the symptom and not the illness. The obvious
solution is to get a bigger monitor, but even that doesn't solve
everything since you can't have a monitor that's infinitely large. Or
This is where SCO Panner comes in. It established a virtual monitor
that can be dozens of times the size of your "real"
monitor. With the push of a button or click of a mouse, you move
around this virtual workspace with an amount of freedom comparable to
having a larger monitor. Just like virtual memory does have drawbacks
over "real" memory, virtual screens have a drawback over a
larger monitor. However, even if you do have a 21" monitor, the
panner can provide you with even more work space.
Functionally, the panner behaves like a viewport or
viewfinder into the larger virtual screen. You can move around
and place your windows anywhere within the workspace. Movement can be
in increments equal to the size of your "real" screen or
you can move around in smaller steps, allowing finer control over
what your viewfinder is currently looking at.
In order to change which window manager you use, you need to change
the .startxrc or sys.startxrc
file. By default the line looks like this:
This starts the standard Motif Window Manager. All you need to do is
change the mwm to pmwm, like this:
Now, start (or restart) your session and you will now have the
panning Motif Window manager. When it starts you will see the panner
"viewer" in the lower left hand corner (by default). It is
divided into four workspace (again, by default). These are numbered
1-4. Workspace 1 is referred to as HOME and you will see this as the
label, instead of a number. Between each workspace is a thin line.
This is the "grid." This simply shows you the boundaries of
the predefined workspaces.
Each workspace is the size of your screen and there are several ways
that you can move around:
Clicking on one of the workspaces in the panner
the ALT key and an arrow
the viewfinder to the area you want
on the autopan function
The first way of moving, clicking on one of the workspaces, will move
you completely into a workspace. That is if you click on one of the
work spaces, you are brought to that workspace and the viewfinder is
completely within that workspace. Even if the viewfinder is over
portions of multiple workareas (entirely possible), clicking on a
workspace brings you there and will move the viewfinder.
If you use the ALT key and an arrow key, you are moved in that
direction one "viewfinder-width". That is, if you are
completely within workarea 3 and press ALT-LEFT_ARROW, you end up
completely within work are 2. However, if you are halfway over
workarea 3 and workarea 4, pressing ALT-LEFT_ARROW moves you to a
place halfway over workarea 2 and workarea 3. There are also options
in the root menu that doing panning.
The viewfinder is represented in the panner window by a gray box, the
size of a work area. By pressing the left pointer button, you can
drag the viewfinder to any workspace. When you release the button,
you are brought to that workspace. Using this method you can move the
viewfinder to a location between workspaces. I have found that the
more the viewfinder resides in one workspace, the more likely it will
actually move completely into that workspace. For example, if
you move the viewfinder so it is 10% over workspace 2 and 90% over
workspace 3, releasing the pointer button brings you completely into
workspace three. The granularity of movement is defined by the
*snapDistanceX and *snapDistanceY resources
Autopanning allows you to move between workspaces by simply
pressing a button and moving the pointer in the appropriate
direction. Autopanning is controlled by a couple of resources. The
first, autoPanStep, is also used to enable and disable autopanning.
This resource determines the percentage of the screen size the
viewfinder moves when autopanning. Setting it to 0 means autopanning
Which key is used to active panning with mouse movements, is
defined by the *autoPanModifier resource. By default this is set to
the Meta (Alt) key. If this is not set, then any time the mouse bumps
against the edge of the viewfinder, it will pan. I suggest leaving
the default or selecting some other key, but do not remove this
resource. If it is not set, then any time you accidentally bump
against the viewfinder, your view is thrown out of whack. How long
the panner must wait after autopanning before the next pan is allow
is defined by the autoPanRepeatSensitivity.
If autopanning is enabled (that is, AutoPanStep > 0 ), the
*autoPanStartOn determine whether autopanning must be first turned on
or not before you can use it. The default is True, so that whenever
pmwm starts and AutoPanStep is greater than 0, autopanning is
activated. Otherwise you must enable it from the root menu or by
pressing ALT+SHIFT+minus. The panning can also be turned off from the
root menu or by pressing ALT+minus.
One concept new to the panner is the idea of nailed
windows. Nailed windows stay put. That is, if you change your
work area, they follow you. Hmmm. If they stay put, they follow you.
Now, that's a contradiction if I ever heard one. Believe me, that's
the way I felt, too. However, think of it not as the windows being
nailed to the panner as a whole, but rather the viewfinder. If they
are nailed to the viewfinder and you move the viewfinder, they stay
within your view.
Aside from allowing you to move from workspace to workspace, the
panner allows you to move clients between different workspace. When
the panner has the focus, you can use pointer button 2 to drag a
window to a new workspace. The nice thing is that regardless of how
they are stacked, all windows will appear with the workspace view in
the panner. Therefore, you can grab any window and move it. I have
run into situation where two windows were the exact same size and
where in the same position. In this case, it was impossible to figure
out which window would be grabbed.
If you don't like the numbers given to the workspaces, you can change
them with the *workAreaNames resource. This is what is used to name
workspace 1 to home. If you arrange your workspaces by function, this
is a good way of keeping track of what is where.
The panner window is just like any other window. There are
resources to name it, change it color and define its geometry. Like
other windows, you can change the size of the panner window. One
side-effect of changing the size of the panner window is that you
change the number of workspaces. By default, there is a single row of
four workspaces. You can make the panner window longer, thereby
increasing the number of workspaces, or you can make it taller, also
increasing the number of workspaces. If you make it taller, then the
windows are number left to right across the top row and continue in
the second and subsequent rows. If you don't like the horizontal
appearance of the panner, you can make it vertical, by simply
changing the shape of the window. You cannot resize the panner window
so that the workspaces with windows in them are removed.
For example, assume we have a workarea that is 3 rows of four
workspaces each. If we place a window in workspace 12 (the lower
right corner) we can no longer decrease the size in either direction.
If we move the window to workspace 8 (right most window in middle
row) we can decrease the number of rows, but not the number of
columns. However, you can disable this by setting the
*pannerResizeNoHide resource to FALSE.
By default the panner map has a scale of 1:10. That is the height of
each workspace in the panner is 1/10th that of a real workspace. This
is defined by the *pannerScaleFactor resource. Unless you have a lot
of clients in each workspace, then I feel that a 1:10 scale is too
big. I use 1:15 because it allows me to identify all the clients in
each workspace, but still doesn't take up too much room. Anything
higher and the individual windows in each workspace run together.
If you want more of a feeling of having a single, larger workspace
that a lot of little workspaces tacked together, you can turn off the
grid by setting the *pannerShowGrid resource to FALSE.
The scologin program is actually a "display manager”
since is displays the graphical login on more than just the system
console. If you are running on X terminals, it is scologin that
allows you to login. In principle, it serves the same functions as
both getty and login.
Normally, scologin is started from /etc/rc2.d/P86scologin
and runs on the second multiscreen,
/dev/tty02. During the install of OpenServer, you are given
the option of enabling or disabling it by default. I prefer to start
X on my own, therefore I always have it disabled. However, if you
have X terminals relying on scologin, this is not a good thing to do.
Instead, you can edit the file /usr/lib/X11/scologin/Xservers.
There is a line saying:
:0 local /usr/bin/X11/X :0 -crt
As you start-up, scologin
uses several scripts to determine what to do and when to do it, all
which reside in
/usr/lib/X11/scosession. The first, Xstartup
defines what scologin should do before beginning the user's session.
Next comes Xsession-<shell>,
where <shell> is the user's login shell. This defines the
basic characteristics of the user's X session. Xreset
defines the actions when the users ends a session.
One thing to keep in mind is that the Xstartup script is run
as root. As such, anything you put in there is run as root. This has
the potential of becoming a security hole. Note that by default, you
don't have to worry too much, as Xstartup
is empty, just waiting for the eager system administrator to fill it
up. One thing the Xstartup
file is useful for is on X-terminals. Since they have no disk of
their own, it is probably necessary to mount the filesystem
containing the user's home directory.
It is only after that scologin has run through the Xsession files
that it starts the X server. This is done with by running startx
script with the -t. The Xsession-<shell> script that is run,
behaves like a user's .profile or .login file, in that it sets up
variables and other aspects of the user's environment.
In the SCO documentation you "are strongly urged to use
scosession to control the
clients." Their point is that if you start them out of either
$HOME/.startxrc or /usr/lib/X11/sys.startxrc,
you may miss certain aspects of that (or other clients), which may
result in the loss of some functionality. Quite true. However, I have
gotten around this.
First, I copied /usr/lib/X11/sys.startxrc
which is a good idea anyway. I next comment out the lines that tested
for the existence of /usr/bin/X11/scosession
and if it was there, ran it. Instead, I just run the two lines that
start a scoterm and the window manager:
2> /dev/null &
pmwm 2> /dev/null
This way I still start all the clients the way SCO "wants”,
but I don't have scosession.
So, just what does scosession
do? First, it's name implies it is responsible for the startup
and shutdown of the X server. The configuration files for scosession
are in $HOME/.odtpref/ScoSession
with the standard X resource information in /usr/lib/X11/ScoSession.
One nice thing about scosession
is that it remembers what you were doing the last time. When you
start up the next time, you are prompted to resume the saved session
or start a new one. The file
$HOME/.odtpref/ScoSession/dynamic contains the information
that was saved from the previous session. That is, what is need to
configure your session when you decide to resume that last session.
The static file contains the resource settings that define your
default session. If this file doesn't exist, the resource
information is take from /usr/lib/X11/sco/ScoSession.
Using X terminals
name implies, X terminals are terminals the run X. In principle, they
function the same way as normal terminals. The X terminal is
responsible for communicating with other devices as well as
displaying the incoming information on the screen. The major
difference (I hope you already guessed) is that the interface is all
graphical. The appearance is no different (not much) from what you
would get running on the system console. X-Terminals can be as large
as console as well as provide color.
You can configure your X-Terminal so that scologin
automatically presents you will a login prompt every time you turn
the terminal. Like "normal” terminals, you are connected
to a host machine where the programs (in this case X clients) are
running. To aid in the communication between host machine and
X-Terminal, SCO can use the X Display Manager Control Protocol
(XDMCP), provided the X-Terminal can use it. One advantage this has
is that connection is immediately re-established to the host when the
terminal is turned back on, and you see the login prompt waiting for
If the X-Terminal does not understand XDMCP, you must include an
entry for that terminal in the /usr/lib/X11/scologin/Xservers
file. Otherwise you don't have to configure the host at
all. Instead, the XDMCP communicates with the SCO machine and hooks
you up. In addition, the terminal must be left powered on at all
times to maintain the connection to the host machine. If you turn it
off, you must manually reconnect it to the host.
On the X-Terminal side of things, there are two ways of configuring
things. Well, three. The first is using XDMCP. If the X-Terminal uses
it, there may be no configuration needed. However, if there is, you
have to determine how the X-Terminal is to contact the host, as some
broadcast a request for a host. When there is an answer, they will
display a list of available hosts from which you can choose. Others
broadcast a request and just accept the first available host.
Once you login, the behavior is the same as if you were on the system
console. If there is an .Xdefaults file in your home directory that
matches the name of the host that you connect to, these will be the
file is used to configure scologin on those X-Terminal that do
support XDMCP (or ones where you don't want to reconfigure it).
The format of the Xservers files
is the same of X-Terminals as it is for scologin. (Makes sense when
one considered you get a scologin
on the X-Terminal.
Security and Authorizations
Because of its very nature, X is not very secure. It sits on a
network, which means that potentially everyone on your network has
access to your machine. This applies to X or any other network
application. The problem is compounded further by X's design. It was
intended to be accessible by others. If you know the name of the
machine, theoretically you could display any client on someone else's
machine. In fact, you could essentially take over control of that
machine including taking over the mouse and even killing the other
person's clients. Fortunately, there aren't any such bad willed
people that perform such senseless acts of aggression. Yeah, right.
Although we haven't yet figured out how to make X completely secure
(other than disconnecting it from the network), there are several
mechanisms that we can use to limit the access to our machine. The
first is based on which host is trying to contact you and is
specified through the files /etc/X?.hosts,
where ? is the display number. Since you more than likely have only
one display, we are only going to talk about X0.hosts.
However, what we talk about will be applicable to any display.
By default, the server only access clients that are running on the
local machine. If we want to add a machine we either add the
machine's name to X0.hosts
or we use the xhost program. The X0.hosts
file is a simple text file containing a list of the hosts that are
authorized to connect. For example, the X0.hosts
file on scoburg might look like this:
Normally, this is sufficient, but in some cases you might need to
include the domain name as well. If any other host tries to start a
client on scoburg's display, they're end up getting something like
Xlib: connection to "siemau"
refused by server
Client is not authorized to connect to Server
Toolkit Error: Can't open
The other mechanism is to use the xhost
program to allow or deny access as needed. Since the X0.hosts
file is usually one writeable by root, xhost
allows users to decided what machines can connect during their
current session. To add a machine the syntax would be:
to remove it:
Note that you cannot add hosts to a remote machine. For example, you
cannot telnet to a machine and run xhost.
If you try, you end up getting a message like this:
scoburg being added to access
must be on local machine to add or remove hosts.
You can also allow access by all hosts with:
However, this is counterproductive as the who idea here is to limit
access to your machine.
Another access control method is the well-named MIT-MAGIC-COOKIE-1.
Why is it well named? Come on! It's a great name! Despite any "logic"
behind the name, I think it's fantastic.
When you logging in X using scologin
a machine-readable code is place in $HOME/.Xauthority.
This code is called a magic cookie and is 128 bits long. The magic
cookies can be thought of as a password that is only known to the
server and the user logging in with scologin.
Unlike regular passwords, users don't actually type in the password,
but rather users run programs to manipulate it. Once established, a
client has to present this password (code) in order to access the
server. The code is obtain by reading .Xauthority,
but since it is (by default) only readable by the owner, only the
user can access it.
With a shared home directory (such as one using NFS) the .Xauthority
file is available to you. If you are on another machine, you need to
use the xauth program to
raid the cookie jar on the other machine to extract the information
and merge it with your own. However, If you don't have access to the
remote .Xauthority file
this won't work. One solution is user equivalence that we talked
about in the section on networking. The other is .rhosts.
Both allow you to define which users and from which machines can
access the .Xauthority
file. However, this also opens other things up.
If you are on the local machine and want to update the .Xauthority
file somewhere else, you would run xauth
If we use the add, merge, or extract functions, then we need to
specify the server. In the first half we are extracting the
authority information from whatever machine we have defined with the
DISPLAY variable, which is
normally the local host. The dash (-) here says we want to write the
output to stdout. If we wanted we could extract the information from
another host by using that name, provided the information was in the
.Xauthority file. Because
we did not use the -f option to specify what file to read, the system
uses the file in the XAUTHORITY
variable, which usually defaults to $HOME/.Xauthority.
In the second half, we are running rsh on the remote host and merging
the authorization information. Here the dash means we are reading
from stdin. We can also extract the authorization information for a
remote machine and merge it with the .Xauthority file on a different
machine. The syntax would be:
We can now take this one step further and extract the authority
information from a remote machine and merge it with the information
locally. Again, assuming we are on siemau and want to extract the
authority information on scoburg, the command would be:
The principles by X may
appear overwhelming at first. By understanding that the different
aspects of X-Windows can be though of different layers building on
each other, it's easier to understand their interactions. My
suggestion now is to play around with your X system and make some
changes and see how the changes effect the behavior and appearance of
your windows and the entire work area. Don't worry, too much. The
worst that can happen is that you need top reinstall.