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
.br
X Window System
.br
X Version 11
X Window System, Version 11
X11
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 \f3Xlib - C Language X Interface\f1 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.
% setenv DISPLAY myws:0 $ DISPLAY=myws:0; export DISPLAY
Finally, most X programs accept a command line option of \f3-display displayname\f1 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 \f3Xlib use can be specified with the environment variable \f3XAUTHORITY, and defaults to the file \f3.Xauthority in the home directory. \f3Xdm uses \f3$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:
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 \f3server's machine, not on the application's.
The default font path for the OpenWindows server is \f3/usr/openwin/lib/fonts\f1.
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, \f3mkfontdir 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 \f3xset 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
-adobe-courier-medium-r-normal--10-100-75-75-m-60-iso8859-1
could be abbreviated as:
-*-courier-medium-r-normal--*-100-*-*-*-*-*-*
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:
#rgb
#rrggbb
#rrrgggbbb
#rrrrggggbbbb
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:
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 "\ 00".
The \f3Xlib routine XGetDefault(3X) and the resource utilities within \f3Xlib and the X Toolkit Intrinsics obtain resources from the following sources:
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 \f3.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 \f3Xlib
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 \f3Xlib (also used by many toolkits) uses standard resources to construct diagnostic messages when errors occur. The defaults for these messages are usually stored in \f3/usr/openwin/lib/XErrorDB\f1. 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
Xlib - C Language X Interface\f1, X Toolkit Intrinsics - C Language Interface\f1, and Using and Specifying X Resources
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.