Much of the "look and feel" of an X environment is determined by the window manager. The window manager generates the "decoration" around the windows. It generates many of the menus. In some versions it generates a tool bar or a box that shows what applications are running. By changing window managers, you can go from a fairly Spartan environment to something that looks rather similar to Windows 95.
Starting X
Most students will connect to our systems using an X terminal or a PC
running X terminal software. In that case you will be in X
immediately.
If you have a workstation on your desk, it may be set up to act just like an X terminal. In that case it will put you directly into X once you've logged in. However some of our workstations leave you with a white screen and a Unix command prompt. In that case, you should run openwin. We recommend making sure that /usr/openwin/bin is in your path, and typing "openwin". However you can also invoke it explicitly, using the command
/usr/openwin/bin/openwin
But before you do this, take a look at the next section. You
may want to do something to choose your X environment before
running openwin the first time.
The Initial X Environment
Once you start X, the behavior you get depends upon the type of
workstation you are using and the way you started X.
Our undergraduates almost always see the same environment, because they access the system via X terminals or PC's acting as X terminals. This document describes this as the "Rutgers Environment", because the "look and feel" is determined by a set of scripts set up at Rutgers a number of years ago. (This does not mean that the current Rutgers staff necessarily like this look and feel.)
If you are an undergraduate, and you don't want to change your environment, you can skip immediately to the Rutgers Environment. Since you get the Rutgers Environment automatically, you don't need to worry about the various vendor-specific enviornments.
However faculty and grad students get a choice among the following environments. Please see the section describing the environment you want. Otherwise, you may get the wrong one.
To setup the Rutgers environment, make sure that you do not have files called .xinitrc or .Xdefaults in your home directory. If you do, remove them or rename them to something else. Once you've done that.
Would you prefer a small, medium, or large font?
Depending upon the exact context, you may be expected to type "s",
"m", or "l", or to choose a button with the mouse. (The program
should make this clear.) Small and medium are 10 or 12 points. Large
is 18 points. If you don't know what to choose, we recommend small or
medium for folks under 30, and large for those of us older folks.
Once you've chosen the font size, you'll need to log in again or restart X.
If you are using a Sun workstation, the x11 script is supposed to set up the Rutgers environment and then start X. For some newer workstations, the attempt to start X will fail. Don't worry. By that point your environment has been set up. You can now start X using /usr/openwin/bin/openwin. In general we recommend starting X with openwin rather than x11. I would only use x11 the first time, or any later time when you want to reinitialize your X environment to the default Rutgers environment.
The Basic Screen
If you haven't done anything to change it, the Rutgers environment
presents a screen with the following elements:
Clock Icon Manager
Mailbox
Getting Started
(X) shell
(X) mail
(X) desktop
RU INFO
At the upper left corner are a clock and a mailbox. The primary purpose of the mailbox is to show when you receive mail. It will raise its flag.
At the lower left is a run box containing several buttons. These let you start common programs. You can change the list of programs that show up here. To start one of the programs, click on its icon with your left mouse button.
At the upper right is something called the "icon manager". (Newer software uses the term "icon box".) It contains an icon for each X application that's running on the system. Often people find that they have so many windows open that they can't find them all. The icon manager lets you see what you've got. Also, you can open or close a window by clicking on its icon in the icon manager. This leads to a useful trick: You can bring a window to the top by clicking on twice in the icon manager. The first time closes it. The second time opens it and puts it on top.
The most useful way to start is by clicking on "shell" in the run box. This will give you a window with "xterm" in it. Xterm gives you a window with a normal Unix command processor in it. (For those of you who know Microsoft Windows, this is equivalent to a "DOS box".) You can click more than once, and get several different windows. Each of these windows acts independently. You can run commands, set environment variables, etc. in one and they generally won't affect the other. (Of course if you do anything that changes a file, that change will be visible everywhere.)
This is really enough information to begin operating in the X environment. As long as you're willing to do things by typing commands, all you need are xterm windows. You can run all other programs by typing their names. Programs that understand about X will create new windows automatically. For example, when you run emacs from an xterm window, it will open a new Emacs window. Similarly, if you use Zmail in GUI mode, it will open a window and use it to display your mail.
The rest of this document will help you tailor your X environment to make things more convenient. For example, it will tell you how to change colors and fonts, and how to cause additional programs to start automatically when you start X. We advise you to use X for a while before doing any of this tailoring.
Setting Your Path
Many of the X applications reside in special X-related directories.
When you login using X, your path is automatically adjusted to
include these directories. However in some cases this isn't
good enough. For example
So in the end, many people end up putting commands in .cshrc to set an appropriate path. Here's a typical example of what might go in .cshrc:
if (`uname` == "OSF1") then
if ("$path" !~ /usr/bin/X11) set path = (/usr/bin/X11 $path)
if ("$path" !~ */usr/local/bin*) set path = \
(/usr/local/bin $path)
else
if (`uname -r` =~ 5.*) then
if ("$path" !~ */local/X11*) set path = \
(/usr/local/X11/bin /usr/openwin/bin $path)
if ("$path" !~ */usr/local/bin*) set path = \
(/usr/local/bin $path)
else
if ("$path" !~ */local/X11*) set path = \
(/usr/local/X11/bin /usr/local/X11R4/bin $path)
if ("$path" !~ */usr/local/bin*) set path = \
(/usr/local/bin $path)
endif
endif
WARNING: the ` character is a backwards quote. On many Postscript printers this will show up as the wrong character.
WARNING: If you copy this, make sure that you don't have any other statements in .cshrc or .login that set the path. Or if you do, make sure that you know how they interact.
This example is not "politically correct". First, you shouldn't need to do this at all. We attempt to set up a good default path for you automatically. If you set up your own path, as in this example, there could be trouble if the staff need to move something. They'll adjust the default path. They won't change you .cshrc file. So you could find that your path is no longer right.
Second, paths should be set in .login, not .cshrc.
Unfortunately, long experience has taught us (1) that not all of the ways into the system get the default path, and (2) not all of the ways into the system take .login. So in practice many users find that they have to set their path in .cshrc.
This example does three interesting things:
Of course you can add directories of your own if you need additional ones. Also, you may want to modify the X11 setup for Solaris:
(/usr/local/X11/bin /usr/openwin/bin $path)
This assumes that you want the Rutgers X environment. If you prefer
to use Sun's software, you might want to use
(/usr/openwin/bin /usr/local/X11/bin $path)
instead.
.xinitrc -- Controlling What Programs Are Started
When you start X, it starts a number of programs for you. The exact
set of programs depends upon which environment you're using. But
normally the initial set of programs includes a window manager, some
sort of run bar or menu setup that lets you start applications, and
possibly something like a clock.
Most people want to modify this list of programs. The most common modification is to add a window with a Unix command processor in it. (This normally uses the program xterm.) It is possible to add or change which programs run, and to specify arguments to change the size or position of the windows.
If you are using the Rutgers environment, the initial set of programs is determined in a script. On Suns, this script is a file called .xinitrc, in your home directory. On most other systems (including Digital Unix), the script is called .xsession.
If you are using the vendor environments (Openwindows for Suns and the DEC Session Manager for Digital Unix) or CDE, you should not use .xinitrc or .xsession. These environments have special tools that make it easy to control what programs are run. They use files other than .xinitrc/.xsession. Thus this section is only relevant for people using the Rutgers environment, or people who want to set up their own private environment.
If you use both Suns and Digital Unix, you should create one of these files and make a symbolic link from the other name. For example:
emacs .xinitrc
ln -s .xinitrc .xsession
This uses emacs to create or edit the file .xinitrc, and adds a
symbolic link so that the name .xsession refers to the same file.
If you start under the Rutgers environment, the startup scripts will create a default .xinitrc for you. The file it creates is a bit more complex than the average, because it has tests to make it do the right thing in various circumstances. For example, if you are on the console of a workstation, it creates a special console window, otherwise it creates a normal command window. If uses a different background color depending upon whether you are on a color display or not. Aside from this sort of complexity, .xinitrc can be very simple. Here's a typical one:
#!/bin/sh
xrdb <$HOME/.Xdefaults
xsetroot -solid aquamarine4
xclock -geometry 75x75-1-1 &
xterm -C -geometry 80x12+0+0 &
xterm -geometry 80x24+0-0 &
twm
Note that this is a script. It must begin with #!/bin/sh, and
it must be set executable. (Use "chmod +x .xinitrc").
This shows the most common things people put in .xinitrc:
The -geometry options specify the size and shape of the window. 80x12+0+0 means a window that is 80 characters wide and 12 lines high, positioned at the upper left. Some applications interpret the window size as characters, others as pixels. The man page will tell you. In general they try to pick whatever makes the most sense. Clearly for a terminal window, most users will find it easier to specify something like 80x24, rather than figuring out how many pixels it takes to give an 80-character wide window. However for a clock, it makes more sense to describe the size in pixels.
The + and - numbers give the location of the window. The first gives the X coodinate and the second gives the Y coordinate. + numbers start from the upper left of the screen. - numbers start from the lower right of the screen. So +0+0 means to put it at the upper left corner, +0-0 puts it at the lower left corner, and -0-0 puts it at the lower right corner. Of course numbers greater than 0 are used to put things in the middle of the screen.
Here's a trick for coming up with the geometry specification: Start up the application and let the system give you the default size and position. Now use the mouse to resize and it move it the way you want. Then run "xwininfo", and click on the window. Xwininfo will print a bunch of information, ending with a -geometry option that describes the current size and location of the window.
The window managers have a large number of options. These affect colors, location of the icon manager, what menus you get, the bindings of F keys, etc. If you're tailoring your X, you'll almost certainly want to configure your window manager. See "man twm", "man fvwm" or "man tvtwm" for details on how to do this. In general this will involve creating or editing a configuration file in your home directory, .twmrc, .tvtwmrc, or .fvwmrc.
xrsh -- Starting processes on another system
You'll often find that you want to open a window on another system.
Perhaps you're using a workstation, and you want to run on a server
with more compute power or specific software that you need.
The simplest approach is to use the "xrsh" command. This command connects to another machine, sends over security information that allows it to access your display, and then starts up a program. In the simplest form, you simply supply a hostname. E.g.
xrsh romulus
will start up a window on romulus with a Unix command processor
in it. This is the most common case. You can also ask for
a specific program to be started. E.g.
xrsh romulus emacs
will start a copy of emacs on romulus, with its display on your
system.
Xrsh will attempt to start a process without a password. This will work if you have .rhosts set up properly, and the system you are connecting to is willing to accept unauthenticated connections from your workstation. Otherwise, xrsh will prompt you for a password on the other machine.
It is important for your path to be correct on the other system. The xrsh startup uses xauth. The directory containing xauth must be in your path. If it isn't, the window will open briefly, print an error message saying it can't find xauth, and close so fast that you probably can't see the message. The moral of the story is to make sure that your path is set up as described in Setting Your Path.
Many people put xrsh commands in their .xinitrc. For example, if you use a workstation, but you do a lot of work on a server, you might want to include the command
xrsh server
in your .xinitrc file. Then you'll get a window on the server
automatically whenever you start up.
There are some compatibility problems involving Digital Unix. If you are using a Digital Unix workstation, xrsh from your workstation to another system should always work. However once you have connected to a Sun, if you want to go to another Sun, you may have to do the xrsh command on your workstation. An attempt to xrsh from one Sun to another may not work. This is a known problem that I thought was fixed, but it seems to have come up again.
xset -- Setting server options
I suggest that you look at the man page for xset, and try the command
xset -q. Xset can be used to set things like the autorepeat,
how sensitive the mouse is, and the font path. For example if
you wanted the mouse much more sensitive than normal, you could
put the command
xset m 10
in your .xinitrc. (10 is an absurdly high value, by the way. You
probably wouldn't want to go above 5.)
The font path is used to specify a list of directories in which fonts can be found. Currently our X servers seem to have fairly good defaults, so I haven't used this option in a while. An example of where you might use it is if you were using the MIT X server and wanted to have access to some special Openwindows fonts (e.g. if you wanted to use the Openwindows window manager). You might put the command
xset fp+ /rutgers/fonts/1/OpenWindows3.0
in your .xinitrc. This would add the directory /rutgers/fonts/1/OpenWindows3.0 to the end of your font path.
xmodmap -- Changing your keyboard
Sometimes you'll find that you want to change your keyboard layout.
You can use xmodmap to do this. See the man page: it has several
good examples. I use it on the Sun keyboard to turn the backspace
key into a delete key. Our software normally assumes that you rub
out typos using a delete. Since the backspace key is in the place
where you'd expect this key to be, it's common to change the backspace
key to generate a delete. I have the following code in my .xinitrc:
if [ `hostname` = "geneva.rutgers.edu" ]; then
xmodmap -e "keysym BackSpace = Delete"
fi
WARNING: the character that shows as ` is actually a backwards single quote. On many printers it shows as a forward single quote.
Note that this tests to see whether the machine is geneva.rutgers.edu. That's my Sun workstation. I also use a Digital Unix workstation. It's keyboard is right. So I only want to change the Sun one.
.Xdefaults -- Options such as Color and Fonts
Most X applications are configurable. You can adjust colors, fonts,
and window size. Often you can set up "accelerators": keys or key
combinations that let you do things from the keyboard rather than the
mouse.
The good news is that there's a common way to specify these things, which is fairly consistent across all X applications. The bad news is that often the documentation doesn't tell you all the properties that can be configured. Getting certain applications to look the way you want can turn into a major intelligence-gathering exercize.
X applications use property-value pairs called "resources". Most of them are stored in a file called .Xdefaults in your home directory. Here's a simple example of .Xinitrc:
XTerm*vt100*font: -bitstream-terminal-
medium-r-normal--25-180-100-100-c-150-iso8859-1
XTerm*vt100*boldFont: -bitstream-terminal-
bold-r-normal--25-180-100-100-c-150-iso8859-1
XTerm*Foreground: black
XTerm*Background: #F0E1B8
*background: white
*foreground: black
mxrn*background: gray30
mxrn*foreground: gray90
mxrn*composeText.background: blue
mxrn*composeText.foreground: white
mxrn*headerText.background: green
mxrn*headerText.foreground: white
NOTE: the font lines were too long to show, so I've broken them at a hyphen. You'd actually need to combine the first pair of lines and the second pair of lines.
NOTE: the mxrn example is made-up. This particular color combination would look terrible.
Note that each line is in the form of an attribute and a value. The attributes are actually patterns, which can include *. As usual, * matches anything. The full names can become quite long, because the names are hierarchical. That is, the color for a specific region may be something like "program.mainwindow.menu.item.text.background". Rather than type all of this out, most people pick enough items to get what they want, and use * for everything else. So this item might be shown as "program*menu*background".
For text, foreground is the color of the text itself. Background is the other color, i.e. the background on which the text is displayed.
Note that the most specific item will be used. Consider the program mxrn. This example specifies foreground and background colors for two specific areas: composeText and headerText. Any other parts of the program will take their colors from the lines
mxrn*background: gray30
mxrn*foreground: gray90
Programs that are not listed will get their color from the lines
*background: white
*foreground: black
The man page for each program should list the resources that that program uses. You really need that documentation so that you know what properties you can set. Unfortunately not all man pages list resources, and some of them give incomplete lists. One good source of information is the app-defaults file. This is discussed in more detail below. This file often lists all the resources that the program uses.
Common Attributes: Color and Font
The most common things to change are colors and fonts. Colors can be
specified in three different ways: by name, with a 6-digit hex code or
with a 12-digit hex code. The basic color model is RGB. That is, a
color is defined by the intensities of red, green and blue. Normally
8 bits are specified for each, i.e. a value between 0 and 255. This
leads to a 6-digit hex code such as #F0E1B8. That is F0 for red, F1
for green, and B8 for blue. (This color is sort of an ivory. It's my
preferred background for text.) Now and then you'll see a 12-digit
version. This uses 4 hex digits for each color. That's more
resolution than you're likely to need.
Color names are defined in the file /usr/lib/X11/rgb.txt. (On a Sun, this will be in /usr/openwin/lib/X11/rgb.txt or /usr/local/X11/lib/X11/rgb.txt.) When I'm trying to find nice colors, I find it useful to look at this file. A reasonable way to try out colors is to open this file in emacs, and then use the command m-x set-background-color or m-x set-foreground-color to see how the color looks. (Just be careful not to set the color to something that makes it impossible to see further commands. If you've got black text on a light background, it would be a bad idea to set the background to black.) (Of course if you're using CDE, the configuration tool has a nicer way to set colors.)
To find the list of fonts available on your system, use the command xlsfonts. Probably you'll want to direct it into a file, e.g.
xlsfonts >fonts
The font names tend to be very long. Here are some examples:
-adobe-courier-bold-r-normal--20-140-100-100-m-110-iso8859-1
-bitstream-terminal-medium-r-normal-sans-18-180-75-75-c-110-
iso8859-1
-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-1
-sony-fixed-medium-r-normal--24-170-100-100-c-120-iso8859-1
(The bitstream name is continued onto a second line.) There's a systematic naming convention that leads to this sort of thing. They include
When you specify a font, you can use * for some components. This allows anything to match. E.g.
-*-courier-medium-r-normal--*-140-*-*-m-*-*-*
would give you a 14 point normal Courier font, from any foundary, leaving
many of the other components unspecified.
Most X servers can scale fonts. So even if a 16-point Courier is not listed, you can set the font to
-*-courier-medium-r-normal--*-160-*-*-m-*-*-*
The server will take another size and scale it. However in most cases
the results won't look very good. Certain fonts are specifically
designed to be scaled. They show 0's for the size in the font
list.
-adobe-courier-medium-r-normal--0-0-0-0-p-0-iso8859-1
There are two good ways to look for fonts. One is to use the program xfontsel. It starts out with all *'s and lets you specify individual fields. (Menus are available to show the possible choices.) It shows you an example of some text in that font. The approach I normally use is to list all the fonts using xlsfonts, and load the list into Emacs. I think use m-x set-default-font to try out fonts. You can avoid a lot of typing by using Emacs commands to put the font name into the cut buffer and then yanking it back into the minibuffer.
It turns out to be surprisingly difficult to find nice-looking fixed-width fonts. Fixed-width fonts are important, because most text-based software wants them. Emacs and xterm don't work very well with proportional fonts. For smaller fonts, courier and lucidatypewriter are reasonable. Most people find the bold versions easier to read. For larger fonts, I recommend the Bitstream terminal fonts. For example, I use the 18 point Bitstream terminal on 1280x1024 displays and the 14 point version on smaller displays.
Class names
Two other items are worth noting. First, for each name there's
both a specific name and a "class". Generally specific names
start with a lowercase letter and classes with an uppercase
letter. The class provides a way to set several different
properties at once. For example, in a complex program you
might allow separate colors to be specified for boldface
characters. This would result in three color specifications:
background, foreground, and boldforeground. In order to let
someone set all of the text colors at once, foreground and
boldforeground would both be in the class Foreground.
So
program*background: white
program*foreground: black
would set only the color of the normal font. The boldface
font would remain whatever color the author of the program
set as the default. If you wanted to set the colors of all
text, you'd need to do
program*Background: white
program*Foreground: black
The man page for a program should tell you what class each of the attributes is in.
There is something similar for programs. If you give a program name in lowercase, it must match the specific copy of the program you are running. Uppercase matches any program of that type. For example, under Digital Unix we have two different versions of emacs. DEC supplies one called xemacs. We have built the latest version of Emacs 19, and called it emacs. If you specified
emacs*Background: white
emacs*Foreground: black
this would set the colors for our emacs, but not for DEC's. Since
DEC's emacs is called xemacs, it won't match a name of "emacs".
However internally, the program knows it's really emacs. If
you used
Emacs*Background: white
Emacs*Foreground: black
it would match both versions of emacs.
Where resources are specified
You can actually specify resources (i.e. attributes and values) in
several different places. The most obvious is .Xdefaults. However
this has a problem. Suppose you work on several different computers.
If you depend upon .Xdefaults, whenever you change a color, you have
to update .Xdefaults on every computer where you run X applications.
If you use different kinds of display, it gets even worse. Suppose
you use a 1280x1024 display in your office and a 640x480 PC at home.
You may very well want to use different fonts at home and at the
office. You can keep different versions of .Xdefault on your two
machines. That will work fine for programs that you run directly on
those machines. But what happens when you connect to a central server
and run programs there? Do you have to change .Xdefaults each time,
in order to get the right font?
Fortunately, there's a simple answer to all of this. The X server can be told to keep a copy of all of your X resources internally. In effect it keeps a copy of .Xdefaults inside the server. When X applications start, they first ask the server what resources it knows about. If resources have been loaded into the server, they take precedence over any .Xdefaults files. So when you work in your office, you can load a file with resources appropriate for a large screen. When you work at home you can load resources appropriate for a small display. Once you've loaded your resources into the X server, all X applications you run will use those resources rather than their local .Xdefaults files.
This is why we said to put the command
xrdb <$HOME/.Xdefaults
at the beginning of .xinitrc. That command tells the server to
load the contents of .Xdefaults.
This is fine if you always work from the same kind of computer, or if you have different home directories on each kind of computer. But suppose that you sometimes use a big screen and sometimes a small screen, and that you have the same home directory in both cases. Then the xrsh command will always load resources from the same copy of .Xdefaults, and you still don't have a way to adjust things.
There's still a solution. It turns out that xrdb passes your .Xdefaults file through the C preprocessor before using it. That means you can use #if statements to specify which parameters are used in different circumstances. Here's an example from my .Xdefaults file:
#if WIDTH==1280
#include ".Xdefaults.disp1280"
#elif WIDTH==1024
#include ".Xdefaults.disp1024"
#elif HEIGHT==864
#include ".Xdefaults.xcursion"
#else
#include ".Xdefaults.disp1024"
#endif
Xterm*vt100*font: NORMAL
XTerm*vt100*boldFont: BOLD
emacs*font: NORMAL
xemacs*font: NORMAL
Note that I include one of three different files, depending upon the display type. xrdb automatically defines a number of symbols, which together describe your display type. If you're careful, you can set up #if statements that select the appropriate include file. To see what symbols are defined for the current display type, use the command "xrdb -symbols". Because of the way CPP works, you should try to use only symbols that have numerical values. In theory you can also test for string values, but this is more complex, and will probably work only if the string doesn't have any periods or spaces.
In my .Xdefaults file, I use generic symbols such as NORMAL or BOLD for all fonts and colors. Then I define those symbols in the include file, appropriately for the particular display I'm on. Here's part of .Xdefaults.disp1280, the file that is used for 1280x1024 displays (in our case, the DEC Alphas):
#define TEXTFG black
#define TEXTBG #F0E1B8
#define MODEFG white
#define MODEBG #da009a006800
If you are using CDE or the DEC environment, note that these environments load .Xdefaults for you.
In addition to .Xdefaults or the resources database within the X server, there are other places that resources may be defined. Some programs have "application default" files. These are specified in the app-defaults subdirectory of the X configuration library directory:
Generally anything you specify should override these application default files. The application default files are useful to look at, because they often list all the resources you can set, and give examples of how to set them. This information should be in the man page, but often isn't.
Many applications also look for a file in your home directory what has the same name as the program (often with the first letter capitalized). For complex programs you may prefer to put the resources in this file rather than .Xdefaults. Depending upon the program, you may have to specify certain resources in this separate file. The man page should explain this.
Finally, it is possible to have a file named .Xdefaults-hostname. That is, .Xdefaults- with the full name of the computer tacked onto the end. At Rutgers, this will be the fully qualified name, e.g. .Xdefaults-romulus.rutgers.edu. This file will be used in place of .Xdefaults when you are on that computer. Unfortunately this turns out to be less useful than it sounds, because it only works for applications actually run on that computer. What you really want is for it to use the name of the system on which the X server is running, no matter what system you're running the application on. Documentation suggests that this is the intent, but it doesn't seem to work that way.
Of course most programs also let you specify options on the command line. See the man page for the program. Normally it's more convenient to put your settings into .Xdefaults. Then you don't have to remember to put them on the command line. However by using the command line you can specify different options each time. For example, in .xinitrc you could start up 3 xterms, and specify a different color for each one.
Directories -- How to Build X Software
This section is aimed at people who want to write or build software
that uses X. It does not include complete instructions: X is an
enormous system. It's not practical for this document to describe how
to write X programs. For that, we recommend the excellent
documentation published by O'Reilly. It's available in bookstores
such as Borders. This section is intended to orient you to the way X
is laid out at Rutgers, and gives some specific advice on which sets
of files to use.
The directory setup at Rutgers is complicated because of the amount of history behind the Rutgers X environment on Suns. Our X setup on Digital Unix is fairly straightforward. Files are where DEC puts them, which is the standard locations used by the original X distribution from MIT. However on the Suns we have two different copies of X. The result is that on various machines we have X in three different locations:
Furthermore, there is a difference in philosophy as to where we put X-based applications that are built at Rutgers. In Digital Unix, we put them in /usr/local/bin, with all other locally built applications. On the Suns, they are often put in the binary area associated with the version of X that they use.
Here are the major X-related directories, as they exist in the various environments:
/usr/local/X11.. means /usr/local/X11R4, X11R5, or X11, as described in the previous section.
In addition, you'll find Motif-related files in /usr/dt, in subdirectories bin, lib and man. Include files are in /usr/include/Xm/. A Rutgers-maintained copy of Motif is on some Suns in appropriate areas of /usr/local/X11..
If you are building X-based software on Suns, make sure you use the -R and -L options to cc or gcc to specify the library directory you want to use. -L is used by the loader when you build the program. -R is used at runtime to find sharable libraries. Normally they should be the same, except that if you need more than one directory, -R takes a list separated by colons and you use a separate -L command for each library.
We recommend that you build new programs using Sun's libraries. That way, your program can be moved to any Sun, and it will still work. That is, we recommend using
-R/usr/openwin/lib -L/usr/openwin/lib,
and if you need Motif
-R/usr/openwin/lib:/usr/dt/lib -L/usr/openwin/lib \
-L /usr/dt/lib
Because of inconsistencies in Sun's libraries, any application default files should be installed in both /usr/openwin/lib/X11/app-defaults and /usr/lib/X11/app-defaults (which at Rutgers is a symbolic link to /usr/local/X11/lib/X11/app-defaults).
If you use xmkmf to build your Makefile, we recommend that you use the one from /usr/openwin/bin. That will include the appropriate Sun directories. (However Sun's xmkmf does not know about Motif. In some cases you may need to add the /usr/dt directories yourself.)
The Openwindows Environment
This section is intended as a very brief description of the desktop
environment you get from Sun under Solaris 2.4 and 2.5. In 2.6 we
expect that Sun will be using CDE. This is intended to give you just
enough information that you can create a terminal emulator window and
change your configuration to get either the Rutgers enviornment or
CDE. If you want to work in the Openwindows Environment, feel free to
experiment: it has fairly good builtin help.
You get Openwindows if you are on a Sun, you don't have a file called .xinitrc, and you run "openwin". So if you want to experiment with Openwindows, you should remove or rename .xinitrc if you have one, and run openwin. If you don't want to use Openwindows, make sure you set up the Rutgers environment (or create your own .xinitrc manually) before running openwin.
Openwin is a script that starts Sun's X server. If you have not set up your own .xinitrc, openwin will start up Sun's Openwindows user environment. (This assumes that /usr/openwin/bin is in your path. If not, you may need to type "/usr/openwin/bin/openwin" rather than simply "openwin". If you're using a Sun workstation, we recommend that you have /usr/openwin/bin in your path.)
The initial screen will have the following items on it:
cmdtool(CONSOLE)
file manager
waste container
However there will be a help viewer on top of the cmdtool and file
manager, mostly obscuring them. If you intend to use Openwindows,
you should use the help viewer. Otherwise, you'll probably want
to close it and start up a shell tool.
Here's a summary of how Openwindows behaves: You'll see a V in the upper left of each window. If you click on it, a menu will pop up that lets you do things to the window. The most useful things are move, size (change the size of the window), close, and quit.
Close can be slightly misleading: most new window systems use the term "close" to mean that you permanently get rid of the window, killing any program associated with it. Sun uses it to mean that the window turns into an icon, but the program is still around. The icon will appear at the lower left of the screen, to show that the program is still there. You can get the window back by clicking on that icon. Most newer systems call this "iconifying" the window, or in Microsoft/Motif terminology, "minimizing" it.
If you want to kill a window permanently, choose "quit".
To move a window, place the mouse pointer in the "title bar" at the top of the window, and drag it with the left mouse button.
If the window is obscured by other windows, but you can still get to the title bar, click on the title bar to raise it to the top. (Alternatively, you can open the window menu for the window that's obscuring it, and lower that window.)
To change the size or shape of a window, "grasp" the corner of the window using the left mouse button and pull it. That corner of the window will move, while the opposite corner remains fixed. That ends up changing the size of the window.
To start applications, place the mouse pointer in the root window (i.e. outside any window). Push down the right button. You'll find a set of cascading menus. The most useful submenus are Applications, Utilities, and Exit. Applications refer to X applications. To get a Unix command processor, choose "Shell tool". This will give you Sun's terminal emulator. Most people find the standard MIT terminal emulator, xterm, much friendlier. (In fact my inclination is to start a shell tool and then type as the first command "xterm &" This will start an xterm.)
If you're going to use Openwindows, you may want to know how to start applications of your own. You can create an .xinitrc file in your home directory. If you do, the openwin command will use it. However in that case you'll be expected to supply a full .xinitrc, complete with your own window manager. This really means you're not using the Openwindows environment anymore. To stay within the Openwindows environment, you should create a file called .openwin-init in your home directory. This is similar to .xinitrc. It contains any X applications that you want to run at startup. However it does not need to call a window manager, because the openwin script will take care of that. A good way to start is to make a copy of Sun's default init file, and then edit it, i.e.
cp /usr/openwin/lib/openwin-init .openwin-init
If you got into the Openwindows environment, but you really want to be in the Rutgers environment, open a shell tool, and do the following:
cp /usr/local/X11/lib/X11/default.xinitrc .xinitrc
cp /usr/local/X11/lib/X11/twm/system.twmrc .tvtwmrc
cp /usr/local/X11/lib/X11/default.Xdefaults.medium .Xdefaults
This will give you the "medium" font size. You can use small or
large in place of medium to get smaller or larger fonts.
Once you've put these files in place, exit from Openwindows: Put the mouse in the root area, push the right mouse button, and choose "Exit". When you're back at the command prompt outside Openwindows, you can type the "openwin" command again. This time you'll get the Rutgers enviornment. See the Rutgers Environment.
This section assumes you are operating on a Sun workstation. If you're using an X terminal, we don't support the Openwindows environment. This is a limitation in the Rutgers setup. (It is possible that you could create a symbolic link from .xsession in your home directory to /usr/openwin/lib/xdm/Xsession. This may work, or it may fail catastrophically. It will certainly cause trouble for you if you also login on a Digital Unix workstation.)
The DEC Session Manager
This section is intended as a very brief description of the desktop
environment you get from DEC under Digital Unix 3.2 and 3.2C. In a
Digital Unix 4.0 DEC will be using CDE. This is intended
to give you just enough information that you can create a terminal
emulator window and change your configuration to get the
Rutgers environment. If you want to work in the DEC
environment, feel free to experiment: it has fairly good builtin help.
You get the DEC environment if you are on a Digital Unix system, and you log in without having a file called .xsession. Unlike our Suns, Digital Unix starts up in X.
The initial screen will have the following items on it:
Session Manager: Digital Equipment
Session Applications Options Help
dxconsole
Console Log
Here's a summary of how the DEC environment behaves:
Note the "Session Manager" at the upper left corner. This is the "master control" for the DEC environment. It has four menus:
The DEC environment uses the Motif window manager. This is a new industry standard. CDE is a superset of it. Here's a summary of how window behave in Motif:
In the upper left corner of the window, you'll see a -. If you click the left mouse button on it, you'll get a menu. This menu lets you choose common window actions, such as changing the size, lowering it (i.e. letting any other windows that may be behind it show), closing it, etc. Note some terminology used in this menu:
Here are some short-cuts for things on the menu:
The DEC environment does not use .xinitrc. It uses a file called .xsession for the same purpose. If .xsession exists, it performs exactly the same function as .xinitrc. In fact, .xinitrc can be a symbolic link to .xinitrc, or the reverse. If .xsession exists, it is supposed to start up whatever applications you want initially, and then run a window manager. Most of the same window managers are available as on the Sun. So you can use the same X setup. However if .xsession is missing, you'll get the DEC environment.
If you are in the DEC environment, you can still specify applications to be started by default. But you can't use .xinitrc (since DEC ignores it) or .xsession (since that will cause the DEC environment not to be started). Instead, you can use the "Option" menu in dxsession to set up applications to start. A file .X11Startup in your home directory can also be used to specify applications to start.
If you got into the DEC environment, but you really want to be in the Rutgers environment, we suggest that you login on a Sun and let it set up your .xinitrc and .Xdefaults. Then create a symbolic link to .xsession:
ln -s .xinitrc .xsession
At the moment, the run bar that is at the lower left of the screen in
the Rutgers environment is not yet installed under Digital Unix. That
will be happening shortly. Other than that, most things available
under X on the Suns are also available under Digital Unix.
In general, the DEC environment is a more modern and standard X environment than the Rutgers one. Unfortunately, it is not available on the Suns. However both are going to be replaced by CDE within about a year.
Even if you decide to use the DEC environment, you'll find that most of this document is applicable. Most of the the sections on customizing X will still apply. The main difference is that instead of .xinitrc, you'll use either .xsession or possibly .X11startup:
If you choose to switch to the Rutgers enviornment, we suggest that you see the Rutgers Environment. If not, the sections starting with Setting Your Path still apply.
The Common Desktop Environment
CDE is the new Unix standard desktop. It is being used by all of the major Unix vendors except SGI. While it's based on a desktop from HP, the actual coding was done by Sun. The versions on Solaris and Digital Unix are essentially identical.
Under Solaris 2.6 and Digital Unix 4.0, there's a new graphical login screen. This will let you choose CDE directly. On the main login screen, you'll see an "Options" button. If you push it, you'll get a small menu that lets you select a language, get a command line login, or select which X environment you want. To select your X environment, choose "Session".
Under Digital Unix "Session" gives you the options "Regular Desktop", which is CDE, or "Dxsession Session", which gets the same behavior as in previous releases. On a Sun, you have the options "Common Desktop Environment (CDE)", which is CDE, or "OpenWindows", which gets the same result as if you ran openwin.
We expect to install this login sometime during the fall of 1996 for Digital Unix and the summer of 1997 for Solaris. If you are running Solaris 2.5.1 and find that you like CDE, you can send mail to help asking them to put dtlogin on your system. I don't believe password handling works correctly in earlier versions of Solaris or in versions of Digital Unix before 4.0. If you don't have the CDE login, you can get CDE as follows:
ln -s /usr/dt/bin/Xsession .xinitrc
ln -s /usr/dt/bin/Xsession .xsession
Here are some of the distinguishing features of CDE: