![[Go to CFHT Home Page]](/images/cfht-icon.gif){kind=icon}
Man Pages 
Back to Software Index 
Manpage Top Level
The X Window System is a network transparent window system developed at MIT which runs on a wide range of computing and graphics machines.
The X Consortium requests that the following names be used when referring to this software:
X supports overlapping hierarchical subwindows and text and graphics operations, on both monochrome and color displays. For a full explanation of the functions that are available, see the Xlib - C Language X Interface manual, the X Window System Protocol specification, the X Toolkit Intrinsics - C Language Interface manual, and various toolkit documents.
Many utilities, window managers, games, toolkits, etc. are available from the user-contributed software. See your site administrator for details.
This information is used by the application to determine how it should connect to the server and which screen it should use by default (on displays with multiple monitors):
On POSIX systems, the default display name is stored in your DISPLAY environment variable. This variable is set automatically by the xterm(1) terminal emulator. However, when you log into another machine on a network, you’ll need to set DISPLAY by hand to point to your display. Examples include,
% setenv DISPLAY myws:0 $ DISPLAY=myws:0; export DISPLAY
Finally, most X programs accept a command line option of -display displayname to temporarily override the contents of DISPLAY. This is most commonly used to pop windows on another person’s screen or as part of a "remote shell" command to start an xterm pointing back to your display. For example,
% xeyes -display joesws:0 -geometry 1000x1000+0+0 % rsh big xterm -display myws:0 -ls </dev/null &
X servers listen for connections on a variety of different communications channels (network byte streams, shared memory, etc.). Since there can be more than one way of contacting a given server, The hostname part of the display name is used to determine the type of channel (also called a transport layer) to be used. The sample servers from MIT support the following types of connections:
The file for authorization which both xdm(1) and Xlib use can be specified with the environment variable XAUTHORITY, and defaults to the file .Xauthority in the home directory. Xdm uses $HOME/.Xauthority and will create it or merge in authorization records if it already exists when a user logs in.
To manage a collection of authorization files containing a collection of authorization records use xauth(1) . This program allows you to extract records and insert them into other files. Using this, you can send authorization to remote machines when you login. As the files are machine-independent, you can also simply copy the files or use NFS to share them. If you use several machines, and share a common home directory with NFS, then you never really have to worry about authorization files, the system should work correctly by default. Note that magic cookies transmitted ‘‘in the clear’’ over NFS or using ftp(1) or rpc(3N) can be ‘‘stolen’’ by a network eavesdropper, and as such may enable unauthorized access. In many environments this level of security is not a concern, but if it is, you need to know the exact semantics of the particular magic cookie to know if this is actually a problem.
The WIDTH and HEIGHT parts of the geometry specification are usually measured in either pixels or characters, depending on the application. The XOFF and YOFF parts are measured in pixels and are used to specify the distance of the window from the left or right and top and bottom edges of the screen, respectively. Both types of offsets are measured from the indicated edge of the screen to the corresponding edge of the window. The X offset may be specified in the following ways:
The Y offset has similar meanings:
Offsets must be given as pairs; in other words, in order to specify either XOFF or YOFF both must be present. Windows can be placed in the four corners of the screen using the following specifications:
In the following examples, a terminal emulator will be placed in roughly the center of the screen and a load average monitor, mailbox, and clock will be placed in the upper right hand corner:
xterm -fn 6x10 -geometry 80x24+30+200 &
xclock -geometry 48x48-0+0 &
xload -geometry 48x48-96+0 &
xbiff -geometry 48x48-48+0 &
Since window managers are regular (albeit complex) client programs, a variety of different user interfaces can be built. OpenWindows comes with a window manager named olwm(1) which supports overlapping windows, popup menus, point-and-click or click-to-type input models, title bars, nice icons, and many other features.
The list of font directories in which the server looks when trying to find a font is controlled by the font path. Although most installations will choose to have the server start up with all of the commonly used font directories, the font path can be changed at any time with the xset(1) program. However, it is important to remember that the directory names are on the server’s machine, not on the application’s.
The default font path for the OpenWindows server is /usr/openwin/lib/fonts.
Font databases are created by running the mkfontdir(1) program in the directory containing the compiled versions of the fonts. Whenever fonts are added to a directory, mkfontdir should be rerun so that the server can find the new fonts. To make the server reread the font database, reset the font path with the xset program. For example, to add a font to a private directory, the following commands could be used:
% cp newfont.fb ~/myfonts
% mkfontdir ~/myfonts
% xset fp rehash
The xlsfonts(1) program can be used to list all of the fonts that are found in font databases in the current font path. Font names tend to be fairly long as they contain all of the information needed to uniquely identify individual fonts. However, the sample server supports wildcarding of font names, so the full specification
could be abbreviated as:
Because the shell also has special meanings for * and ?, wildcarded font names should be quoted:
% xlsfonts -fn ’-*-courier-medium-r-normal--*-100-*-*-*-*-*-*’
If more than one font in a given directory in the font path matches a wildcarded font name, the choice of which particular font to return is left to the server. However, if fonts from more than one directory match a name, the returned font will always be from the first such directory in the font path.
Colors are usually specified by their commonly-used names (for example, red, white, or medium slate blue). The server translates these names into appropriate screen colors using a color database that can usually be found in /usr/openwin/lib/rgb.txt . Color names are case-insensitive, meaning that red, Red, and RED all refer to the same color.
Many applications also accept color specifications of the following form:
where r, g, and b are hexadecimal numbers indicating how much red, green, and blue should be displayed (zero being none and ffff being on full). Each field in the specification must have the same number of digits (e.g., #rrgb or #gbb are not allowed). Fields that have fewer than four digits (e.g. #rgb) are padded out with zero’s following each digit (e.g. #r000g000b000). The eight primary colors can be represented as:
black #000000000000 (no color at all) red #ffff00000000 green #0000ffff0000 blue #00000000ffff yellow #ffffffff0000 (full red and green, no blue) magenta #ffff0000ffff cyan #0000ffffffff white #ffffffffffff (full red, green, and blue)
Unfortunately, RGB color specifications are highly unportable since different monitors produce different shades when given the same inputs. Similarly, color names aren’t portable because there is no standard naming scheme and because the color database needs to be tuned for each monitor.
Application developers should take care to make their colors tailorable.
The X keyboard model is broken into two layers: server-specific codes (called keycodes) which represent the physical keys, and server-independent symbols (called keysyms) which represent the letters or words that appear on the keys. Two tables are kept in the server for converting keycodes to keysyms:
Although most programs deal with keysyms directly (such as those written with the X Toolkit Intrinsics), most programming libraries provide routines for converting keysyms into the appropriate type of string (such as ISO Latin-1).
that are read in from various places when an application is run. By convention, the application name is the same as the program name, but with the first letter capitalized (e.g. Bitmap or Emacs) although some programs that begin with the letter ‘‘x’’ also capitalize the second letter for historical reasons. The precise syntax for resources is:
ResourceLine = Comment | ResourceSpec
Comment = "!" string | <empty line>
ResourceSpec = WhiteSpace ResourceName WhiteSpace ":" WhiteSpace value
ResourceName = [Binding] ComponentName {Binding ComponentName}
Binding = "." | "*"
WhiteSpace = {" " | "\t"}
ComponentName = {"a"-"z" | "A"-"Z" | "0"-"9" | "_" | "-"}
value = string
string = {<any character not including "\n">}
Note that elements enclosed in curly braces ({...}) indicate zero or more occurrences of the enclosed elements
To allow values to contain arbitrary octets, the 4-character sequence \nnn, where n is a digit in the range of "0"-"7", is recognized and replaced with a single byte that contains this sequence interpreted as an octal number. For example, a value containing a NULL byte can be stored by specifying "\000".
The Xlib routine XGetDefault(3X) and the resource utilities within Xlib and the X Toolkit Intrinsics obtain resources from the following sources:
Program resources are organized into groups called classes, so that collections of individual resources (each of which are called instances) can be set all at once. By convention, the instance name of a resource begins with a lowercase letter and class name with an upper case letter. Multiple word resources are concatenated with the first letter of the succeeding words capitalized. Applications written with the X Toolkit Intrinsics will have at least the following resources:
Most applications using the X Toolkit Intrinsics also have the resource foreground (class Foreground), specifying the color to use for text and graphics within the window.
By combining class and instance specifications, application preferences can be set quickly and easily. Users of color displays will frequently want to set Background and Foreground classes to particular defaults. Specific color instances such as text cursors can then be overridden without having to define all of the related resources. For example,
bitmap*Dashed: off
XTerm*cursorColor: gold
XTerm*multiScroll: on
XTerm*jumpScroll: on
XTerm*reverseWrap: on
XTerm*curses: on
XTerm*Font: 6x10
XTerm*scrollBar: on
XTerm*scrollbar*thickness: 5
XTerm*multiClickTime: 500
XTerm*charClass: 33:48,37:48,45-47:48,64:48
XTerm*cutNewline: off
XTerm*cutToBeginningOf3ine: off
XTerm*titeInhibit: on
XTerm*ttyModes: intr ^c erase ^? kill ^u
XLoad*Background: gold
XLoad*Foreground: red
XLoad*highlight: black
XLoad*borderWidth: 0
emacs*Geometry: 80x65-0-0
emacs*Background: #5b7686
emacs*Foreground: white
emacs*Cursor: white
emacs*BorderColor: white
emacs*Font: 6x10
xmag*geometry: -0-0
xmag*borderColor: white
If these resources were stored in a file called .Xresources in your home directory, they could be added to any existing resources in the server with the following command:
% xrdb -merge $HOME/.Xresources
This is how the openwin startup script merges user-specific defaults into any site-wide defaults. All sites are encouraged to set up convenient ways of automatically loading resources. See the Xlib manual section Using the Resource Manager for more information.
% xrdb -load $HOME/.Xresources
% xmodmap -e "keysym BackSpace = Delete"
% mkfontdir /usr/local/lib/otherfonts
% xset fp+ /usr/local/lib/otherfonts
% xmodmap $HOME/.keymap.km
% xsetroot -solid ’#888’
% xset b 100 400 c 50 s 1800 r on
% xset q
% olwm
% xmag
% xclock -geometry 48x48-0+0 -bg blue -fg white
% xeyes -geometry 48x48-48+0
% xbiff -update 20
% xlsfonts ’*helvetica*’
% xlswins -l
% xwininfo -root
% xdpyinfo -display joesworkstation:0
% xhost -joesworkstation
% xrefresh
% xwd | xwud
% bitmap companylogo.bm 32x32
% xcalc -bg blue -fg magenta
% xterm -geometry 80x66-0-0 -name myxterm $*
The default error handler in Xlib (also used by many toolkits) uses standard resources to construct diagnostic messages when errors occur. The defaults for these messages are usually stored in /usr/openwin/lib/XErrorDB. If this file is not present, error messages will consist of error codes only.
When the X Toolkit Intrinsics encounter errors converting resource strings to the appropriate internal format, no error messages are usually printed. This is convenient when it is desirable to have one set of resources across a variety of displays (e.g. color vs. monochrome, lots of fonts vs. very few, etc.), although it can pose problems for trying to determine why an application might be failing. This behavior can be overridden by the setting the StringConversionsWarning resource.
To force the X Toolkit Intrinsics to always print string conversion error messages, the following resource should be placed at the top of the file that gets loaded onto the RESOURCE_MANAGER property using the xrdb(1) program (frequently called .Xresources or .Xres in the user’s home directory):
*StringConversionWarnings: on
To have conversion messages printed for just a particular application, the appropriate instance name can be placed before the asterisk:
xterm*StringConversionWarnings: on
The following copyright and permission notice outlines the rights and restrictions covering most parts of the core distribution of the X Window System from MIT. Other parts have additional or different copyrights and permissions; see the individual source files.
Copyright 1984, 1985, 1986, 1987, 1988, and 1989, by the Massachusetts Institute of Technology.
Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of MIT not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. MIT makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty.
This software is not subject to any license of the American Telephone and Telegraph Company or of the Regents of the University of California.