xclock Analog/Digital Clock
Name
xclock – continuously display the time in either analog or digital form.
Syntax
xclock [options]
Description
xclock continuously displays the time of day, either in digital or analog form. In digital form, xclock displays the time using a 24-hour clock. It also displays the day, month, and year. In analog form, xclock displays a standard 12-hour clock face. You can set up more than one clock simultaneously.
The default clock is an analog clock with a black foreground on a white background. If you want to change the clock's appearance, type in the appropriate options. For example,
xclock -bd slateblue -fg navyblue -hl darkslategrey &
sets up a conventional 12-hour clock with a slate blue window border, navy blue tick marks, and dark slate grey hands.
By default, the clock is positioned in the upper-left corner of your background window. If you are running the default version of mwm, the window manager will place the clock in the upper-left quadrant of the screen, offset from the corner.
Options
xclock accepts all of the standard X Toolkit command line options, which are listed on the X reference page. (We've included some of the more commonly used Toolkit options later in this section.) In addition, xclock accepts the following application-specific options:
-help
Displays a brief summary of xclock's calling syntax and options.
-analog
Draws a conventional 12-hour clock face with tick marks for each minute and stroke marks for each hour. This is the default.
-digital or -d
Displays the date and time in digital format. Note that -display must be used to specify a display.
-chime
Indicates that the clock should chime once on the half hour and twice on the hour.
-hd color
Specifies the color of the hands on an analog clock. The default is black.
-hl color
Specifies the color of the edges of the hands on an analog clock. Only useful on color displays. The default is black.
Specifies the width in pixels of the space between the window border and any portion of the xclock display. The default is 10 pixels in digital mode and 8 pixels in analog mode.
-update seconds
Specifies the frequency in seconds with which xclock updates its display. If the xclock window is obscured and then exposed, xclock overrides this setting and redisplays immediately. A value of less than 30 seconds will enable a second hand on an analog clock. The default is 60 seconds.
The following standard X Toolkit options are commonly used with xclock:
-bw pixels
Specifies the width in pixels of the border around the xclock window. The default is 2 pixels.
-fg color
Determines the color of the text in digital mode, and the color of the tick and stroke marks in analog mode. The default is black.
-fn font
Specifies the font to be used in digital mode. Any fixed-width font may be used. The default is 6x10.
-geometry geometry
Sets xclock window size and location according to the geometry specification. The -geometry option can be (and often is) abbreviated to -g, unless there is a conflicting option that begins with “g.” The argument to the geometry option (geometry) is referred to as a “standard geometry string,” and has the form widthxheight±xoff±yoff.
In digital mode, height and width are determined by the font in use, unless otherwise specified. In analog mode, width and height defaults are 164 pixels, unless otherwise specified. The default value for any unspecified x or y offset is −0. All values are in pixels. If you do not specify the geometry, the window manager may place the window; if not, xclock will ask you for placement when it starts up.
-display [host]:server[.screen]
Allows you to specify the host, server, and screen on which to create the xclock window. See “Options” on the X reference page for an example of usage.
Note that -display cannot be abbreviated to -d, which is shorthand for xclock's -digital option.
-xrm resourcestring
Specifies a resource string to be used. This is especially useful for setting resources that do not have separate command line options.
Resources
xclock uses the Athena Clock widget. It understands all of the core resource names and classes as well as the new resources defined by the Clock widget. Resources you may want to set in user resource files include:
update (class Interval)
Specifies the frequency in seconds at which the time should be redisplayed.
hands (Class Foreground)
Specifies the color of the insides of the clock's hands. The default is the foreground color.
highlight (class Foreground)
Specifies the color used to highlight the clock's hands. The default is the foreground color.
analog (class Boolean)
Specifies whether or not an analog clock should be used instead of a digital one. The default is true.
chime (class Boolean)
Specifies whether or not a bell should be rung on the half hour and on the hour. The default is false.
padding (class Margin)
Specifies the amount of internal padding in pixels to be used. The default is 8.
You may also want to set the following core resources:
width (class Width)
Specifies the width of the clock.
height (class Height)
Specifies the height of the clock.
background (class Background)
Determines the background color. The default is white.
foreground (class Foreground)
Specifies the color for the tick marks and stroke marks. Using the class specifies the color for all things that normally would appear in the foreground color. The default is black since the core default for background is white.
font (class Font)
Specifies the font to be used for the digital clock. Note that variable-width fonts currently will not always display correctly.
reverseVideo (class ReverseVideo)
Specifies that the foreground and background colors should be reversed.
Widget Hierarchy
In order to specify resources, it is useful to know the hierarchy of the widgets which compose xclock. In the notation below, indentation indicates hierarchical structure. The widget class name is given first, followed by the widget instance name.
XClock xclock
Clock clock
Files
/usr/lib/X11/app-defaults/XClock Specifies default resources (as of Release 4).
Bugs
xclock believes the system clock.
When in digital mode, the string should be centered automatically.
No way to exit the program.
See Also
X, oclock, xrdb, time(3C), Athena Clock widget.
Authors
Tony Della Fera (MIT-Athena, DEC);
Dave Mankins (MIT-Athena, BBN);
Ed Moy (UC Berkeley).
xcol Display/Change Color Preferences
Name
xcol – display colors and change color entries in resource files.
Syntax
xcol [options] [filename]
Description
xcol displays the colors defined in the rgb.txt file of the X server. The colors are sorted by their names and their RGB-values and shown in a cube in the ColorView window (The positions represent the RGB-values). Since there usually are more colors defined in the file than cells in the colormap, entries with the same name, but different RGB-values for different intensities, are grouped together.
If a filename is given as a parameter, all occurrences of color names in that file are shown in a second window, called the TextView window. To change the colors specified in the file, a text line has to be made active. Then a new color can be selected in the ColorView window.
To get a better impression of the color, a help (highlight/background) color can be selected for each text line. If two lines define a foreground and a background color, an association can be made and the colors of both lines can be selected together.
Pointer Commands
In the ColorView window, pointer clicks have the following effects:
First button:
Selects color for the active resource line in the TextView window.
Second button:
Selects help (i.e., highlight) color for the active resource line in the TextView window.
Third button:
Moves pointer to the pixel of the color specified by the active resource line in the TextView window.
In the TextView window, pointer clicks have the following effects:
First button:
Selects the text line as the active line.
Second button:
Toggles reverse video mode or connects/disconnects two associated lines (e.g., background and foreground color specifications for the same resource).
Third button:
Highlights the line in the text file.
Options
-rv
Color positions are reversed in the cube. Some new colors can become visible in the area of the very bright colors.
-bnumber
The size of color blocks is set to the constant number. By default, it depends on the size of the ColorView window.
Sets the maximum number of associated colors to number. By default, this value is 11. (You can see the effect when reaching the grey field, where 101 associated entries are possibly available)
-darknumber
Sets the percentage of the intensity of other colors. The default is 50. It's easier to select a color if the screen is darkened a little bit.
+char_list
Adds characters in char_list to list of ‘space’ characters. A color string in the text file must occur between 2 ‘space’ characters to be recognized. By default, these characters are “ ”, “ ”, “ ”, “:”, “””.
-strings
Specifies that names of colors in the file are only recognized when used in a string (useful for C source code). This means that the list of “space” characters is set to “”” only.
-case
Specifies that all occurrences of color names in the wrong case are replaced by the appropriate color names from the rgb.txt file.
-help
Prints some instructions (e.g., on the usage of buttons).
-file filename
Specifies an alternative file to the rgb.txt file.
Files
/usr/lib/X11/rgb.txt
See Also
X; Chapter 8, Other Clients; Chapter 9, Command Line Options.
Bugs
The author wanted the program to work with the selection mechanism used in xterm (when no text file is given), but it seems to be too complicated. So, the current version always stores the string of the color in CUT_BUFFER0. If anyone has an easy way to use the correct selection mechanism, please contact the author.
Copyright
Copyright 1990, University of Kaiserslautern.
Permission to use, copy, modify, and distribute this software for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies.
Author
Helmut Hoenig ([email protected]).
xcutsel Cut Buffer/Selection Interchange
Name
xcutsel – interchange between cut buffer and selection.
Syntax
xcutsel [options]
Description
xcutsel is used to copy the current selection into a cut buffer and to make a selection that contains the current contents of the cut buffer. It acts as a bridge between applications that don't support selections and those that do.
By default, xcutsel will use the selection named PRIMARY and the cut buffer CUT_BUFFER0. Either or both of these can be overridden by command line arguments or by resources.
An xcutsel window has the following buttons:
quit
When this button is pressed, xcutsel exits. Any selections held by xcutsel are automatically released.
copy PRIMARY to 0
When this button is pressed, xcutsel copies the current selection into the cut buffer.
copy 0 to PRIMARY
When this button is pressed, xcutsel converts the current contents of the cut buffer into the selection.
The button labels reflect the selection and cut buffer selected by command line options or through the resource database.
When the copy 0 to PRIMARY button is activated, the button will remain inverted as long as xcutsel remains the owner of the selection. This serves to remind you which client owns the current selection. Note that the value of the selection remains constant; if the cut buffer is changed, you must again activate the copy button to retrieve the new value when desired.
Options
xcutsel accepts all of the standard X Toolkit command line options, which are listed an the X reference page. In addition, xcutsel accepts the following application-specific options:
-selection name
Specifies the name of the selection to use. The default is PRIMARY. The only supported abbreviations for this option are -select, -sel, and -s, since the standard Toolkit option -selectionTimeout has a similar name.
-cutbuffer number
Specifies the cut buffer to use. The default is cut buffer 0.
Resources
This program accepts all of the standard X Toolkit resource names and classes as well as:
selection (class Selection)
This resource specifies the name of the selection to use. The default is PRIMARY.
This resource specifies the number of the cut buffer to use. The default is 0.
Widgets
xcutsel is made up of the following widgets.
xcutsel xcutsel
Box box
Command sel-cut
Command cut-sel
Command quit
If you specify a different selection or cut buffer to use, you will probably also want to customize the labels of the buttons. Unfortunately, it isn't obvious which button widget name corresponds to the current labels. Here's the correspondence, in case you need to change the labels:
sel-cut
This is the button normally labeled copy PRIMARY to 0.
cut-sel
This is the button normally labeled copy 0 to PRIMARY.
quit
This is the quit button.
Bugs
There is no way to change the name of the selection or the number of the cut buffer while the program is running.
See Also
X, xterm, xclipboard; Chapter 5, The xterm Terminal Emulator; Text widget information in Chapter 8, Other Clients, and Appendix G, Athena Widget Resources.
Author
Ralph R. Swick, DEC/MIT Project Athena.
xditview Display ditroff Files
Name
xditview – display ditroff DVI files.
Syntax
xditview [options]
Description
The xditview program displays ditroff output on an X display. It uses special font metrics that match the font set distributed with X11 Release 3, so it does not require access to the server machine for font loading.
Options
xditview accepts all of the standard X Toolkit command line options, which are listed on the X reference page. (We've included one of the more commonly used Toolkit options later in this section.) In addition, xditview accepts the following application-specific options:
-help
Indicates that a brief summary of the allowed options should be printed.
-page
Specifies the page number of the document to be displayed.
-backingStore backing_store_type
Redisplay of the DVI window can take up to a second or so. This option causes the server to save the window contents so that when it is scrolled around the viewport, the window is painted from contents saved in backing store. backing_store_type can be one of Always, WhenMapped, or NotUseful.
The following standard X Toolkit option is commonly used with xditview:
-fn font
Specifies the font to be used for displaying widget text. The default is fixed.
Resources
This program uses the Dvi widget in the Athena Widget Set. It understands all of the core resource names and classes as well as:
width (class Width)
Specifies the width of the window.
height (class Height)
Specifies the height of the window.
foreground (class Foreground)
Specifies the default foreground color.
font (class Font)
Specifies the font to be used for error messages.
Using xditview with ditroff
To build a DVI file suitable for use with xditview, use the device description in the subdirectory devX75 (under xditroff in the MIT source tree). ditroff looks for the font files in the directory /usr/lib/font, so the appropriate font files must be installed, and referenced by ditroff's -T option, as shown its the following example:
$ cd devX75 $ makedev DESC $ mkdir /usr/lib/font/devX75 $ cp *.out /usr/lib/font/devX75 $ ditroff -TX75 ditroff_input | xditview
See Also
X, xrdb, ditroff(1).
Bugs
xditview can be easily confused by attempting to display a DVI file constructed for the wrong device. Support for pic is not yet implemented.
Authors
Portions of this program originated in xtroff which was derived from suntroff.
Keith Packard MIT X Consortium);
Richard L. Hyde (Purdue);
David Slattengren (Berkeley);
Malcom Slaney (Schlumberger Palo Alto Research);
Mark Moraes (University of Toronto).
xdm X Display Manager
Name
Syntax
xdm [options]
Description
xdm manages a collection of X displays, both local and possibly remote—the emergence of X terminals guided the design of several parts of this system, along with the development of the X Consortium standard XDMCP, the X Display Manager Control Protocol (introduced in Release 4). It is designed to provide services similar to that provided by init, getty, and login on character terminals: prompting for login/password, authenticating the user, and running a “session.”
A session is defined by the lifetime of a particular process; in the traditional character-based terminal world, it is the user's login shell process. In the xdm context, it is an arbitrary session manager. This is because, in a windowing environment, a user's login shell process would not necessarily have any terminal-like interface with which to connect.
Until real session managers become widely available, the typical xdm substitute would be either a window manager with an exit option, or a terminal emulator running a shell—with the condition that the lifetime of the terminal emulator is the lifetime of the shell process that it is running—thus degenerating the X session to an emulation of the character-based terminal session.
When the session is terminated, xdm resets the X server and (optionally) restarts the whole process.
Because xdm provides the first interface that users will see, it is designed to be simple to use and easy to customize to the needs of a particular site. xdm has many options, most of which have reasonable defaults. Browse through the various sections, picking and choosing the things you want to change. Pay particular attention to The Xsession File, which will describe how to set up the style of session desired.
Options
First, note that all of these options, except -config, specify values that can also be specified in the configuration file as resources.
-config configuration_file
Specifies a resource file which specifies the remaining configuration parameters. If no file is specified and the file /usr/lib/X11/xdm/xdm-config exists, xdm will use it.
-daemon
Specifies true as the value for the DisplayManager.daemonMode resource. This makes xdm close all file descriptors, disassociate the controlling terminal, and put itself in the background when it first starts up (just like the host of other daemons). It is the default behavior.
-debug debug_level
Specifies the numeric value for the DisplayManager.debugLevel resource. A non-zero value causes xdm to print piles of debugging statements to the terminal; it also disables the DisplayManager.daemonMode resource, forcing xdm to run synchronously. To interpret these debugging messages, a copy of the source code for xdm is almost a necessity. No attempt has been made to rationalize or standardize the output.
-error error_log_file
Specifies the value for the DisplayManager.errorLogFile resource. This file contains errors from xdm as well as anything written to standard error by the various scripts and programs run during the progress of the session.
-nodaemon
Specifies false as the value for the DisplayManager.daemonMode resource.
-resources resource_file
Specifies the value for the DisplayManager*resources resource. This file is loaded using xrdb to specify configuration parameters for the authentication widget.
-server server_entry
Specifies the value for the DisplayManager.servers resource. (See “Resources” below.)
-udpPort port_number
Specifies the value for the DisplayManager.requestPort resource. This sets the port number which XDM will monitor for XDMCP requests. As XDMCP uses the registered well-known udp port 177, this resource should probably not be changed except for debugging. (Available as of Release 4.)
-session session_program
Specifies the value for the DisplayManager*session resource. This indicates the program to run when the user has logged in as the session. (Available as of Release 4.)
-xrm resource_specification
Allows an arbitrary resource to be specified, just as most toolkit applications.
Resources
At many stages the actions of xdm can be controlled through the use of the configuration file, which is in the familiar X resource format. See Chapter 10 for a description of the resource file format. Some resources modify the behavior of xdm on all displays, while others modify its behavior on a single display. Where actions relate to a specific display, the display name is inserted into the resource name between “DisplayManager” and the final resource name segment. For example, DisplayManager.expo_0.startup is the name of the resource that defines the startup shell file on the “expo:0” display. Because the resource manager uses colons to separate the name of the resource from its value and dots to separate resource name parts, xdm substitutes underscores for the dots and colons when generating the resource name. (The use of underscores to separate the parts of the display name is new in Release 4. In Release 3, DisplayManager.expo.0.startup is the resource. The Release 3 xdm substitutes dots for the colons when generating the resource name.)
Specifies either a filename full of server entries, one per line, or a single server entry. Each entry indicates a display that should constantly be managed and that is not using XDMCP. (If the resource value begins with a slash, it is assumed to be the name of a file containing the list.) Each entry consists of at least three parts: a display name, a display class (new as of Release 4), and a display type. Local servers will also have a command line to start the server. (The program name should be an absolute UNIX pathname, since xdm does not search through the directories of the PATH environment variable.) Foreign servers can have a comment in place of the command line. A typical entry for local display number 0 would be:
:0 Digital-QV local /usr/bin/X11/X :0
The display types are:
local A local display, i.e., one that has a server program to run.
foreign A remote display, i.e., one that has no server program to run.
The display name must be something that can be passed in the -display option to any X program. This string is used in the display-specific resources to specify the particular display, so be careful to match the names (e.g., use :0 local/usr/bin/X11/X :0 instead of localhost:0 local /usr/bin/X11/X :0 if your other resources are specified as DisplayManager._0.session).
The display class portion can also be used in display-specific resources, as the class name of the resource. This is useful if you have a large collection of similar displays (perhaps several X terminals) and would like to set resources for groups of them. When using XDMCP, the display is required to specify the display class. Your X terminal documentation should describe a reasonably standard display class string for your device.
DisplayManager.requestPort
Indicates the UDP port number which xdm uses to listen for incoming XDMCP requests. Unless you need to debug the system, leave this with its default value of 177. (Available as of Release 4.)
DisplayManager.errorLogFile
Error output is normally directed at the system console. To redirect, it simply set this resource to any filename. A method to send these messages to syslog should be developed for systems that support it; however the wide variety of “standard” interfaces precludes any system-independent implementation. This file also contains any output directed to standard error by Xstartup, Xsession, and Xreset, so it will contain descriptions of problems in those scripts as well.
DisplayManager.debugLevel
A non-zero value specified for this integer resource will enable reams of debugging information to be printed. It also disables daemon mode, which would redirect the information into the bit-bucket. Specifying a non-zero debug level also allows non-root users to run xdm, which would normally not be useful. (Available as of Release 4.)
DisplayManager.daemonMode
Normally, xdm attempts to make itself into an unassociated daemon process. This is accomplished by forking and leaving the parent process to exit, then closing file descriptors and mangling the controlling terminal. When attempting to debug xdm, this is quite bothersome. Setting this resource to false will disable this feature. (Available as of Release 4.)
DisplayManager.pidFile
The filename specified will be created to contain an ASCII representation of the process ID of the main xdm process. This is quite useful when reinitializing the system. xdm also uses file locking to attempt to eliminate multiple daemons running on the same machine, which would cause quite a bit of havoc. (Available as of Release 4.)
DisplayManager.lockPidFile
Controls whether xdm uses file locking to keep multiple xdm processes from running amok. On System V, this uses the lockf library call, while on BSD it uses flock. The default value is true. (Available as of Release 4.)
DisplayManager.remoteAuthDir
This is a directory name that xdm uses to temporarily store authorization files for displays using XDMCP. The default value is /usr/lib/X11/xdm. (Available as of Release 4.)
DisplayManager.autoRescan
This Boolean controls whether xdm rescans the configuration file and servers file after a session terminates and the files have changed. By default it is true. You can force xdm to reread these files by sending a SIGHUP to the main process. (Available as of Release 4.)
DisplayManager.removeDomainname
When computing the display name for XDMCP clients, the resolver will typically create a fully qualified host name for the terminal. Since this is sometimes confusing, xdm will remove the domain name portion of the host name if it is the same as the domain name for the local host when this variable is set. By default the value is true. (Available as of Release 4.)
DisplayManager.keyFile
XDM-AUTHENTICATION-1 style XDMCP authentication requires that a private key be shared between xdm and the terminal. This resource specifies the file containing those values. Each entry in the file consists of a display name and the shared key. By default, xdm does not include support for XDM-AUTHENTICATION-1 as it requires DES, which is not generally distributable. (Available as of Release 4.)
DisplayManager.DISPLAY.resources
Specifies the name of the file to be loaded by xrdb as the resource database onto the root window of screen 0 of the display. This resource database is loaded just before the authentication procedure is started, so it can control the appearance of the “login” window. See “Authentication Widget Resources,” which describes the various resources which are appropriate to place in this file. There is no default value for this resource, but the conventional name is /usr/lib/X11/xdm/Xresources.
DisplayManager.DISPLAY.xrdb
Specifies the program used to load the resources. By default, xdm uses /usr/bin/X11/xrdb.
DisplayManager.DISPLAY.cpp
Specifies the name of the C preprocessor used by xrdb. (Available as of Release 4.)
DisplayManager.DISPLAY.startup
Specifies a program which is run (as root) after the authentication process succeeds. By default, no program is run. The conventional name for a file used here is Xstartup. See “The Xstartup File” below.
DisplayManager.DISPLAY.session
Specifies the session to be executed (not running as root). By default, /usr/bin/X11/xterm is run. The conventional name is Xsession. See “The Xsession File” below.
DisplayManager.DISPLAY.reset
Specifies a program which is run (as root) after the session terminates. Again, by default no program is run. The conventional name is Xreset. See “The Xreset File” below.
DisplayManager.DISPLAY.openDelay,
DisplayManager.DISPLAY.openRepeat,
DisplayManager.DISPLAY.openTimeout,
DisplayManager.DISPLAY.startAttempts
Numeric resources control the behavior of xdm when attempting to open intransigent servers. openDelay is the length of the pause (in seconds) between successive attempts. openRepeat is the number of attempts to make. openTimeout is the amount of time to, wait while actually attempting the open (i.e., the maximum time spent in the connect syscall). startAttempts (available as of Release 4) is the number of times this entire process is done before giving up on the server. After openRepeat attempts have been made, or if openTimeout seconds elapse in any particular attempt, xdm terminates and restarts the server, attempting to connect again. This process is repeated startAttempts times, at which point the display is declared dead and disabled. Although this behaviour may seem arbitrary, it has been empirically developed and works quite well on most systems. The default values are 5 for openDelay, 5 for openRepeat, 30 for openTimeout, and 4 for startAttempts.
DisplayManager.DISPLAY.pingInterval,
DisplayManager.DISPLAY.pingTimeout
To discover when remote displays disappear, xdm occasionally “pings” them, using an X connection and sending XSync requests. pingInterval specifies the time (in minutes) between each ping attempt, pingTimeout specifies the maximum amount of time (in minutes) to wait for the terminal to respond to the request. If the terminal does not respond, the session is declared dead and terminated. By default, both are set to 5 minutes. xdm will not ping local displays. Although it would seem harmless, it is unpleasant when the workstation session is terminated as a result of the server hanging for NFS service and not responding to the ping. (Available as of Release 4.)
DisplayManager.DISPLAY.terminateServer
Specifies whether the X server should be terminated when a session terminates (instead of resetting it). This option can be used when the server tends to grow without bound over time in order to limit the amount of time the server is run. The default value is false.
DisplayManager.DISPLAY.userPath
xdm sets the PATH environment variable for the session to this value. It should be a colon separated list of directories; see sh(1) for a full description. The default value can be specified in the X system configuration file with DefUserPath; frequently it is set to :/bin:/usr/bin:/usr/bin/X11:/usr/ucb.
DisplayManager.DISPLAY.systemPath
xdm sets the PATH environment variable for the startup and reset scripts to the value of this resource. The default for this resource is specified with the DefaultSystemPath entry in the system configuration file, but it is frequently /etc:/bin:/usr/bin:/usr/bin/X11:/usr/ucb. Note the conspicuous absence of “.” from this entry. This is a good practice to follow for root; it avoids many common trojan horse system penetration schemes.
DisplayManager.DISPLAY.systemShell
xdm sets the SHELL environment variable for the startup and reset scripts to the value of this resource. By default, it is /bin/sh.
DisplayManager.DISPLAY.failsafeClient
If the default session fails to execute, xdm will fall back to this program. This program is executed with no arguments, but executes using the same environment variables as the session would have had. See “The Xsession File” below. By default, /usr/bin/X11/xterm is used.
DisplayManager.DISPLAY.grabServer
DisplayManager.DISPLAY.grabTimeout
To eliminate obvious security shortcomings in the X protocol, xdm grabs the server and keyboard while reading the name and password. The grabServer resource specifies if the server should be held for the duration of the name and password reading; when false, the server is ungrabbed after the keyboard grab succeeds, otherwise the server is grabbed until just before the session begins. The grabTimeout resource specifies the maximum time xdm will wait for the grab to succeed. The grab may fail if some other client has the server grabbed, or possibly if the network latencies are very high. This resource has a default value of 3 seconds; you should be cautious when raising it, as a user can be spoofed by a look-alike window on the display. If the grab fails, xdm kills and restarts the server (if possible) and session. (Available as of Release 4.)
DisplayManager.DISPLAY.authorize
DisplayManager.DISPLAY.authName
authorize is a Boolean resource that controls whether xdm generates and uses authorization for the server connections. If authorization is used, authName specifies the type to use. Currently, xdm supports only MIT-MAGIC-COOKIE-1 authorization; XDM-AUTHORIZATION-1 could be supported as well, but DES is not generally distributable. XDMCP connections specify which authorization types are supported dynamically, so authName is ignored in this case. When authorize is set for a display and authorization is not available, the user is informed by having a different message displayed in the login widget. By default, authorize is true and authName is MIT-MAGIC-COOKIE-1. (Available as of Release 4.)
DisplayManager.DISPLAY.authFile
This file is used to communicate the authorization data from xdm to the server, using the -auth server command line option. It should be kept in a directory which is not world-writable, as it could easily be removed, disabling the authorization mechanism in the server. (Available as of Release 4.)
DisplayManager.DISPLAY.resetForAuth
The original implementation of authorization in the sample server reread the authorization file at server reset time, instead of when checking the initial connection. As xdm generates the authorization information just before connecting to the display, an old server would not get up-to-date authorization information. This resource causes xdm to send SIGHUP to the server after setting up the file, causing an additional server reset to occur, during which time the new authorization information will be read. (Available as of Release 4.)
DisplayManager.DISPLAY.userAuthDir
When xdm is unable to write to the usual user authorization file ($HOME/.Xauthority), it creates a unique file name in this directory and points the environment variable XAUTHORITY at the created file. By default, it uses /tmp. (Available as of Release 4.)
Controlling The Server
xdm controls local servers using POSIX signals. SIGHUP is expected to reset the server, closing all client connections and performing other clean up duties. SIGTERM is expected to terminate the server. If these signals do not perform the expected actions, xdm will not perform properly.
To control remote servers not using XDMCP, xdm searches the window hierarchy on the display and uses the protocol request KillClient in an attempt to clean up the terminal for the next session. This may not actually kill all of the clients, as only those which have created windows will be noticed. XDMCP provides a more certain mechanism; when xdm closes its initial connection, the session is over and the terminal is required to close all other connections.
Controlling xdm
xdm responds to two signals: SIGHUP and SIGTERM. When sent a SIGHUP, xdm rereads the file specified by the DisplayManager.servers resource and notices if entries have been added or removed. If a new entry has been added, xdm starts a session on the associated display. Entries that have been removed are disabled immediately, meaning that any session in progress will be terminated without notice, and no new session will be started.
When sent a SIGTERM, xdm terminates all sessions in progress and exits. This can be used when shutting down the system.
xdm attempts to mark the various subprocesses for ps(1) by editing the command line argument list in place. Because xdm can't allocate additional space for this task, it is useful to start xdm with a reasonably long command line (15 to 20 characters should be enough). Each process that is servicing a display is marked -<Display_Name>.
Authentication Widget Resources
The authentication widget reads a name/password pair from the keyboard. As this is a toolkit client, nearly every imaginable parameter can be controlled with a resource. Resources for this widget should be put into the file named by DisplayManager.DISPLAY.resources. All of these resources have reasonable default values, so it is not necessary to specify any of them.
xlogin.Login.width, xlogin.Login.height, xlogin.Login.x,
xlogin.Login.y
The geometry of the login widget is normally computed automatically. If you wish to position it elsewhere, specify each of these resources.
xlogin.Login.foreground
The color used to display the typed-in user name.
xlogin.Login.font
The font used to display the typed-in user name.
xlogin.Login.greeting
A string which identifies this window. The default is “Welcome to the X Window System”.
xlogin.Login.unsecureGreeting
When X authorization is requested in the configuration file for this display and none is in use, this greeting replaces the standard greeting. Its default value is “This is an unsecure session”. (Available as of Release 4.)
xlogin.Login.greetFont
The font used to display the greeting.
xlogin.Login.greetColor
The color used to display the greeting.
The string displayed to prompt for a user name. xrdb strips trailing white space from resource values, so to add spaces at the end of the prompt (usually a nice thing), add spaces escaped with backslashes. (In Release 3, Control-A should work.) The default is “Login:”.
xlogin.Login.passwdPrompt
The string displayed to prompt for a password. The default is “Password:”.
xlogin.Login.promptFont
The font used to display both prompts.
xlogin.Login.promptColor
The color used to display both prompts.
xlogin.Login.fail
A message which is displayed when the authentication fails. The default is “Login Failed, please try again”.
xlogin.Login.failFont
The font used to display the failure message.
xlogin.Login.failColor
The color used to display the failure message.
xlogin.Login.failTimeout
The time (in seconds) that the fail message is displayed. The default is 30 seconds.
xlogin.Login.translations
This specifies the translations used for the login widget. See Chapter 10, Setting Resources, and Appendix F, Translation Table Syntax, for more information on translations. The default translation table for xdm is:
Ctrl<Key>H: delete-previous-character() Ctrl<Key>D: delete-character() Ctrl<Key>B: move-backward-character() Ctrl<Key>F: move-forward-character() Ctrl<Key>A: move-to-begining() Ctrl<Key>E: move-to-end() Ctrl<Key>K: erase-to-end-of-line() Ctrl<Key>U: erase-line() Ctrl<Key>X: erase-line() Ctrl<Key>C: restart-session() Ctrl<Key>\: abort-session() <Key>BackSpace: delete-previous-character() <Key>Delete: delete-previous-character() <Key>Return: finish-field() <Key>: insert-char()
The actions that are supported by the widget are:
delete-previous-character
Erases the character before the cursor.
delete-character
Erases the character after the cursor.
move-backward-character
Moves the cursor backward one character.
move-forward-character
Moves the cursor forward one character.
move-to-beginning
Moves the cursor to the beginning of the editable text.
move-to-end
Moves the cursor to the end of the editable text.
erase-to-end-of-line
Erases all text after the cursor.
erase-line
Erases the entire text.
finish-field
If the cursor is in the name field, proceeds to the password field; if the cursor is in the password field, check the current name/password pair. If the name/password pair is valid, xdm starts the session. Otherwise, the failure message is displayed and the user is prompted to try again.
abort-session
Terminates and restarts the server.
abort-display
Terminates the server, disabling it. This is a rash action and is not accessible in the default configuration. It can be used to stop xdm when shutting the system down, or when using xdmshell.
restart-session
Resets the X server and starts a new session. This can be used when the resources have been changed and you want to test them, or when the screen has been overwritten with system messages.
insert-char
Inserts the character typed.
set-session-argument
Specifies a single word argument which is passed to the session at startup. See “The Xsession File” and “Typical Usage” below.
Disables access control in the server, this can be used when the .Xauthority file cannot be created by xdm. Be very careful when using this; it might be better to disconnect the machine from the network first. (Available as of Release 4.)
The Xstartup File
This file is typically a shell script. It is run as root and should be very careful about security. This is the place to put commands which make fake entries in /etc/utmp, mount users' home directories from file servers, display the message of the day, or abort the session if logins are not allowed. Various environment variables are set for the use of this script:
DISPLAY
is set to the associated display name.
HOME
is set to the home directory of the user.
USER
is set to the user name.
PATH
is set to the value of DisplayManager.DISPLAY.systemPath.
SHELL
is set to the value of DisplayManager.DISPLAY.systemShell.
XAUTHORITY
may be set to a non-standard authority file (Release 4).
No arguments of any kind are passed to the script. xdm waits until this script exits before starting the user session. If the exit value of this script is non-zero, xdm discontinues the session immediately and starts another authentication cycle.
The Xsession File
This is the script that is run as the user's session. It is run with the permissions of the authorized user, and has several environment variables specified:
DISPLAY
is set to the associated display name.
HOME
is set to the home directory of the user.
USER
is set to the user name.
PATH
is set to the value of DisplayManager.DISPLAY.userPath.
SHELL
is set to the user's default shell (from /etc/passwd).
XAUTHORITY
may be set to a non-standard authority file (Release 4).
At most installations, Xsession should look in $HOME for a file .xsession, which would contain commands that each user would like to use as a session. This would replace the system default session. Xsession should also implement the system default session if no user-specified session exists. See “Typical Usage” below.
An argument may be passed to this program from the authentication widget using the “set-session-argument” action. This can be used to select different styles of session. One very good use of this feature is to allow the user to escape from the ordinary session when it fails. This would allow users to repair their own .xsession if it fails, without requiring administrative intervention. The section “Typical Usage” demonstrates this feature.
The Xreset File
Symmetrical with Xstartup, this script is run after the user session has terminated. Run as root, it should probably contain commands that undo the effects of commands in Xstartup, removing fake entries from /etc/utmp or unmounting directories from file servers. The collection of environment variables that were passed to Xstartup is also given to Xreset.
Typical Usage
Actually, xdm is designed to operate in such a wide variety of environments that “typical” is probably a misnomer. However, this section will focus on making xdm a superior solution to traditional means of starting X from /etc/ttys or manually.
First off, the xdm configuration file should be set up. A good thing to do is to make a directory (/usr/lib/X11/xdm comes immediately to mind) that will contain all of the relevant files. Here is a reasonable configuration file for Release 4, which could be named xdm-config:
DisplayManager.servers: /usr/lib/X11/xdm/Xservers DisplayManager.errorLogFile: /usr/lib/X11/xdm/xdm-errors DisplayManager.pidFile: /usr/lib/X11/xdm/xdm-pid DisplayManager*resources: /usr/lib/X11/xdm/Xresources DisplayManager*session: /usr/lib/X11/xdm/Xsession DisplayManager._0.authorize: true DisplayManager*authorize: false
As you can see, the xdm-config file primarily contains references to other files. Note that some of the resources are specified with “*” separating the components. These resources can be made unique for each different display by replacing the “*” with the display name, but normally this is not very useful. See the “Resources” section for a complete discussion.
The first file, /usr/lib/X11/xdm/Xservers, contains the list of displays to manage. Most workstations have only one display, numbered 0, so the file will look like this:
:0 display_class local /usr/bin/X11/X :0
This will keep /usr/bin/X11/X running on this display and manage a continuous cycle of sessions.
The file /usr/lib/X11/xdm/xdm-errors will contain error messages from xdm and anything output to standard error by Xstartup, Xsession or Xreset. When you have trouble getting xdm working, check this file to see if xdm has any clues to the trouble.
The next configuration entry, /usr/lib/X11/xdm/Xresources, is loaded onto the display as a resource database using xrdb. As the authentication widget reads this database before starting up, it usually contains parameters for that widget:
xlogin*login.translations: #override\e <Key>F1: set-session-argument(failsafe) finish-field()\en\e <Key>Return: set-session-argument() finish-field() xlogin*borderWidth: 3 #ifdef COLOR xlogin*greetColor: #f63 xlogin*failColor: red xlogin*Foreground: black xlogin*Background: #fdc #else xlogin*Foreground: black xlogin*Background: white #endif
The various colors specified here look reasonable on several of the displays we have, but may look awful on other monitors. As X does not currently have any standard color naming scheme, you might need to tune these entries to avoid disgusting results. Please note the translations entry; it specifies a few new translations for the widget which allow users to escape from the default session (and avoid troubles that may occur in it). Note that if #override is not specified, the default translations are removed and replaced by the new value, not a very useful result as some of the default translations are quite useful (like <Key>: insert-char(), which responds to normal typing).
The Xstartup file used here simply prevents login while the file /etc/nologin exists. As there is no provision for displaying any messages here (there isn't any core X client which displays files), the user will probably be baffled by this behavior. I don't offer this as a complete example, but simply a demonstration of the available functionality.
Here is a sample Xstartup script:
#!/bin/sh
#
# Xstartup
#
# This program is run as root after the user is verified
#
if [ -f /etc/nologin ]; then
exit 1
fi
exit 0
The most interesting script is Xsession. This version recognizes the special “failsafe” mode, specified in the translations in the Xresources file above, to provide an escape from the ordinary session:
#!/bin/sh # # Xsession # # This is the program that is run as the client # for the display manager. This example is # quite friendly as it attempts to run a per-user # .xsession file instead of forcing a particular # session layout case $# in 1) case $1 in failsafe) exec xterm -geometry 80x24-0-0 -ls ;; esac esac startup=$HOME/.xsession resources=$HOME/.Xresources # # check for a user-specific session and execute it # # Note: the -x flag to test is not supported in all versions of # unix, check with local authorities before proceeding … # if [ -f $startup ]; then if [ -x $startup ]; then exec $startup else exec /bin/sh $startup fi else # # a simple default session. Check to see # if the user has created a default resource file # and load it, start the universal window manager # and use xterm as the session control process. # if [ -f $resources ]; then xrdb -load $resources fi twm & exec xterm -geometry 80x24+10+10 -ls fi
No Xreset script is necessary, so none is provided in Release 4.
Some Other Possibilities
You can also use xdm to run a single session at a time, using the 4.3 init options or other suitable daemon by specifying the server on the command line:
% xdm -server “:0 SUN-3/60CG4 local /usr/bin/X :0”
Or, you might have a file server and a collection of X terminals. The configuration for this could look identical to the sample above, except the Xservers file might look like:
extol:0 VISUAL-19 foreign exalt:0 NCD-19 foreign explode:0 NCR-TOWERVIEW3000 foreign
This would direct xdm to manage sessions on all three of these terminals. See “Controlling xdm” above for a description of using signals to enable and disable these terminals in a manner reminiscent of init.
One thing that xdm isn't very good at doing is coexisting with other window systems. To use multiple window systems on the same hardware, you'll probably be more interested in xinit.
See Also
X, xinit, XDMCP.
Author
Keith Packard, MIT X Consortium.
xdpr Dump Window Directly to Printer
Name
xdpr – dump an X window directly to the printer.
Syntax
xdpr [filename] [options]
Description
xdpr runs the commands xwd, xpr, and lpr(1) to dump an X window, process it for a laser printer, and print it out. This is the easiest way to get a printout of a window. xdpr by default will print the largest possible representation of the window on the output page.
Options
The options for xdpr are the same as those for xpr, xwd, and lpr(1). The most commonly used options are described below; see the reference pages for these commands for detailed descriptions of the many other options available.
filename
Specifies an existing file containing a window dump (created by xwd) to be printed instead of selecting an X window.
-Pprinter
Specifies the name of the printer to be used. If a printer name is not specified here, xdpr (really, lpr(1)) will send your output to the printer specified by the PRINTER environment variable. Be sure that the type of the printer matches the type specified with the -device option.
-device printer_device
Specifies the device on which the file is to be printed. Currently the following printers are supported:
1n03
Digital LN03.
1a100
Digital LA100.
ljet
HP LaserJet series and other monochrome PCL devices, such as ThinkJet, QuietJet, RuggedWriter, HP2560 series, and HP2930 series printers. (Available as of Release 4.)
pJet
HP PaintJet (color mode). (Available as of Release 4.)
pjetxl
HP PaintJet XL Color Graphics Printer (color mode). (Available as of Release 4.)
pp
IBM PP3812.
ps
PostScript printer.
-help
Displays the list of options known to xdpr.
-display [host]:server[.screen]
Allows you to specify the server to connect to. host specifies the machine, server specifies the server number, and screen specifies the screen number. For example,
xdpr -display your_node:0.1
prints a dump of an X window from screen 1 of server 0 on the machine your_node. If the host is omitted, the local machine is assumed. If the screen is omitted, screen 0 is assumed; the server and colon (:) are necessary in all cases.
Any other arguments will be passed to the xwd, xpr, and lpr(1) commands as appropriate for each.
Environment Variables
PRINTER
Specifies which printer to use by default.
See Also
X, xwd, xpr, xwud, 1pr(1).
Authors
Paul Boutin, MIT Project Athena;
Michael R. Gretzinger, MIT Project Athena;
Jim Gettys, MIT Project Athena.
xdpyinfo Display Information Utility
Name
xdpyinfo – display information utility for X.
Syntax
xdpyinfo [option]
Description
xdpyinfo is a utility for displaying information about an X server. It is used to examine the capabilities of a server, the predefined values for various parameters used in communicating between clients and the server, and the different types of screens and visuals that are available.
Option
xdpyinfo accepts the following option:
-display [host]:server[.screen]
Specifies the display about which xdpyinfo should display information. host specifies the machine, server specifies the server number, and screen specifies the screen number. By default, xdpyinfo displays information about all screens on the display. For example,
xdpyinfo -display your_node:0.0
displays information about all screens of server 0 of the machine your_node. If the hostname is omitted, the local node is assumed. If the screen is omitted, screen 0 is assumed. The server and colon (:) are necessary in all cases.
Sample Output
The following example shows the output produced by xdpyinfo when connected to a display that supports an 8-plane screen and a 1-plane screen.
name of display: :0.0
version number: 11.0
vendor string: MIT X Consortium
vendor release number: 4
maximum request size: 16384 longwords (65536 bytes)
motion buffer size: 0
bitmap unit, bit order, padding: 32, MSBFirst, 32
image byte order: MSBFirst
number of supported pixmap formats: 2
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
keycode range: minimum 8, maximum 129
number of extensions: 4
SHAPE
MIT-SHM
Multi-Buffering
MIT-SUNDRY-NONSTANDARD
default screen number: 0
number of screens: 2
screen #0:
dimensions: 1152x900 pixels (325x254 millimeters)
resolution: 90x90 dots per inch
depths (2): 1, 8
root window id: 0x8006e
depth of root window: 8 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x8006b
default number of colormap cells: 256
preallocated pixels: black 1, white 0
options: backing-store YES, save-unders YES
current input event mask: 0xd0801d
KeyPressMask ButtonPressMask ButtonReleaseMask
EnterWindowMask ExposureMask SubstructureRedirectMask
PropertyChangeMask ColormapChangeMask
number of visuals: 6
default visual id: 0x80065
visual:
visual id: 0x80065
class: PseudoColor
depth: 8 planes
size of colormap: 256 entries
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x80066
class: DirectColor
depth: 8 planes
size of colormap: 8 entries
red, green, blue masks: 0x7, 0x38, 0xc0
significant bits in color specification: 8 bits
visual:
visual id: 0x80067
class: GrayScale
depth: 8 planes
size of colormap: 256 entries
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x80068
class: StaticGray
depth: 8 planes
size of colormap: 256 entries
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 8 bits
visual:
visual id: 0x80069
class: StaticColor
depth: 8 planes
size of colormap: 256 entries
red, green, blue masks: 0x7, 0x38, 0xc0
significant bits in color specification: 8 bits
visual:
visual id: 0x8006a
class: TrueColor
depth: 8 planes
size of colormap: 8 entries
red, green, blue masks: 0x7, 0x38, 0xc0
significant bits in color specification: 8 bits
number of mono multibuffer types: 6
visual id, max buffers, depth: 0x80065, 0, 8
visual id, max buffers, depth: 0x80066, 0, 8
visual id, max buffers, depth: 0x80067, 0, 8
visual id, max buffers, depth: 0x80068, 0, 8
visual id, max buffers, depth: 0x80069, 0, 8
visual id, max buffers, depth: 0x8006a, 0, 8
number of stereo multibuffer types: 0
screen #1:
dimensions: 1152x900 pixels (325x254 millimeters)
resolution: 90x90 dots per inch
depths (1): 1
root window id: 0x80070
depth of root window: 1 plane
number of colormaps: minimum 1, maximum 1
default colormap: 0x8006c
default number of colormap cells: 2
preallocated pixels: black 1, white 0
options: backing-store YES, save-unders YES
current input event mask: 0xd0801d
KeyPressMask ButtonPresslask ButtonReleaseMask
EnterWindowMask ExposureMask SubstructureRedirectMask
PropertyChangeMask ColormapChangeMask
number of visuals: 1
default visual id: 0x80064
visual:
visual id: 0x80064
class: StaticGray
depth: 1 plane
size of colormap: 2 entries
red, green, blue masks: 0x0, 0x0, 0x0
significant bits in color specification: 1 bits
number of mono multibuffer types: 1
visual id, max buffers, depth: 0x80064, 0, 1
number of stereo multibuffer types: 0
See Also
Author
Jim Fulton, MIT X Consortium.
xedit Text Editor for X
Name
xedit – simple text editor for X.
Syntax
xedit [options] [filename]
Description
xedit provides a window consisting of the following four areas:
Commands Section
A set of commands that allow you to exit xedit, save the file, or load a new file into the edit window.
Message Window
Displays xedit messages. In addition, this window can be used as a scratch pad.
Filename Display
Displays the name of the file currently being edited, and whether this file is Read-Write or Read Only.
Edit Window
Displays the text of the file that you are editing or creating.
The xedit window appears in Figure 8-13 in Part Two of this guide.
Command Buttons
Quit
Quits the current editing session. If any changes have not been saved, xedit displays a warning message, allowing the user to save the file.
Save
If file backups are enabled (see “Resources”), xedit stores a copy of the original, unedited file in <prefix>filename<suffix>, then overwrites the filename with the contents of the edit window. The filename is retrieved from the Text widget directly to the right of the Load button.
Load
Loads the file named in the Text widget immediately to the right of this button and displays it in the Edit Window. If the currently displayed file has been modified, a warning message will ask the user to save the changes or to press Load again.
Editing
The Athena Text widget is used for the three sections of this application that allow text input, namely the Message Window, the the Edit Window, and the window to the right of the command buttons, in which a filename can be entered.
The characters typed will go to the Text widget that the pointer is currently over. If the pointer is not over a Text widget, then the keypresses will have no effect on the application. This is also true for the special key sequences that pop-up dialog widgets; so, for example, typing Control-S in the filename widget (next to the command buttons) will enable searching in that widget, not the Edit Window (edit widget).
Both the Message Window and the Edit Window will create a scrollbar if the text to display is too large to fit in that window. Horizontal scrolling is not allowed by default, but can be turned on through the Text widget's resources. See Appendix G, Athena Widget Resources, for more information.
The following list summarizes the editing commands recognized by xedit (i.e., by the Text widget).
Control-A
Move to the beginning of the current line.
Control-B
Move backward one character.
Control-D
Delete the next character.
Control-E
Move to the end of the current line.
Control-F
Move forward one character.
Control-H or
Delete the previous character.
Backspace
Return Control-J,
New paragraph. (Linefeed, Control-J, and Control-M may be unreliable on some terminals.)
Control-M, or
LineFeed
Control-K
Kill the rest of this line. (Does not kill the carriage return at the end of the line. To do so, use Control-K twice. However, be aware that the second kill overwrites the text line in the kill buffer.)
Control-L
Redraw the window. (Also scrolls text so that cursor is positioned in the middle of the window.)
Control-N
Move down to the next line.
Control-O
Divide this line into two lines at this point.
Control-P
Move up to the previous line.
Control-V
Move down to the next screenful of text.
Control-W
Kill the selected text.
Control-Y
Insert the last killed text. (If the last killed text is a carriage return—see Control-K above—a blank line is inserted.)
Control-Z
Scroll up the text one line.
Meta-<
Move to the beginning of the file.
Meta->
Move to the end of the file.
Meta-[
Move backward one paragraph.
Meta-]
Move forward one paragraph.
Move backward one word.
Meta-D
Kill the next ward.
Meta-F
Move forward one word.
Meta-H, or
Kill the previous word.
Meta-Delete
Meta-I
Insert a file. If any text is selected, use the selected text as the filename. Otherwise, a dialog box will appear in which you can type the desired filename.
Meta-V
Move up to the previous screenful of text.
Meta-Y
Insert the last selected text here. Note that this can be text selected in some other text subwindow. Also, if you select some text in an xterm window, it may be inserted in an xmh window with this command. Pressing pointer button 2 is equivalent to this command.
Meta-Z
Scroll down the text one line.
Delete
Delete the previous character.
Note that a translation in the app-defaults file overrides the translation for the Return key for the text window in which a filename can be entered (next to the command buttons); in this window only, instead of starting a new line, Return moves the editing cursor to the end of the current line.
Options
xedit accepts all of the standard X Toolkit command line options, which are listed on the X reference page. In addition, xedit accepts the following argument:
filename
Specifies the file that is to be loaded during start up. This is the file that will be edited. If a file is not specified, xedit lets you load a file or create a new file after it has started up.
Widget Hierarchy
In order to specify resources, it is useful to know the hierarchy of the widgets which compose xedit. In the notation below, indentation indicates hierarchical structure. The widget class name is given first, followed by the widget instance name.
Xedit xedit
Paned paned
Paned buttons
Command quit
Command save
Command load
Text filename
Label bc_label
Text messageWindow
Label labelWindow
Text editWindow
See Appendix G, Athena Widget Resources for a list of resources that can be set for the Athena widgets.
Application Resources
The available application resources are:
enableBackups (class EnableBackups)
Specifies that, when edits made to an existing file are saved, xedit is to copy the original version of that file to <prefix>filename<suffix> before it saves the changes. The default value for this resource is “off,” stating that no backups should be created.
backupNamePrefix (class BackupNamePrefix)
Specifies a string that is to be prepended to the backup filename. The default is that no string shall be prepended.
backupNameSuffix (class BackupNameSuffix)
Specifies a string that is to be appended to the backup filename. The default is to append the string “.BAK”.
Files
/usr/lib/X11/app-defaults/Xedit—Specifies required resources (Release 4).
Restrictions
There is no undo function.
See Also
X, xrdb, Appendix G, Athena Widget Resources.
Copyright
Copyright © 1988, Digital Equipment Corporation. Copyright © 1989, Massachusetts Institute of Technology.
Author
Chris D. Peterson, MIT X Consortium.
xev Print X Events
Name
xev – print contents of X events.
Syntax
xev [options]
Description
xev creates a window and then asks the X server to send it notices, called events, whenever anything happens to the window (such as being moved, resized, typed in, clicked in, etc.). It is useful for seeing what causes events to occur and to display the information that they contain.
xev was included in the Release 3 standard distribution; in Release 4, it has been moved to demos. We feel it is sufficiently useful that we continue to document it here.
Options
xev accepts the following options:
-display [host]:server[.screen]
Allows you to specify the host, server, and screen to connect to. host specifies the machine, server specifies the server number, and screen specifies the screen number. For example,
xev -display your_node:0.1
specifies screen 1 of server 0 on the machine your_node. Either or both the host and screen elements can be omitted. If host is omitted, the local machine is assumed. If screen is omitted, screen 0 is assumed (and the period is unnecessary). The colon and server are necessary in all cases.
-geometry geometry
The xev window is created with the specified size and location determined by the supplied geometry specification. The -geometry option can be (and often is) abbreviated to -g, unless there is a conflicting option that begins with “g.” The argument to the geometry option (geometry) is referred to as a “standard geometry string,” and has the form widthxheight±xoff±yoff.
-bw pixels
Specifies the width of the window border in pixels.
See Also
X, xwininfo, xdpyinfo; Volume One, Xlib Programming Manual; Volume Zero, X Protocol Reference Manual.
Author
Jim Fulton, MIT X Consortium.
xfd Font Displayer
Name
xfd – X window font displayer.
Syntax
xfd [options] -fn fontname
Description
xfd creates a window containing the name of the font being displayed, a row of command buttons, several lines of text for displaying character metrics, and a grid containing one glyph per cell. The characters are shown in increasing order from left to right, top to bottom. The first character displayed at the top left will be character number 0 unless the -start option has been supplied, in which case the character with the number given in the -start option will be used.
The characters are displayed in a grid of boxes, each large enough to hold any single character in the font. Each character glyph is drawn using the PolyText16 request (used by the Xlib routine XDrawString16). If the -box option is given, a rectangle will be drawn around each character, showing where an ImageText16 request (used by the Xlib routine XDrawImageString16) would cause background color to be displayed.
The origin of each glyph is normally set so that the character is drawn in the upper left corner of the grid cell. However, if a glyph has a negative left bearing or an unusually large ascent, descent, or right bearing (as is the case with the cursor font), some characters may not appear in their own grid cells. The -center option may be used to force all glyphs to be centered in their respective cells.
All the characters in the font may not fit in the window at once. To see the next page of glyphs, press the Next button at the top of the window. To see the previous page, press Prev. To exit xfd, press Quit.
Individual character metrics (index, width, bearings, ascent, and descent) can be displayed at the top of the window by pressing on the desired character.
The font name displayed at the top of the window is the full name of the font, as determined by the server. See xlsfonts for ways to generate lists of fonts, as well as more detailed summaries of their metrics and properties.
Options
xfd accepts all of the standard X Toolkit command line options, which are listed on the X reference page. In addition, xfd accepts the following application-specific options. (Note that the option -fn font is required.)
-fn font
Specifies the font to be displayed.
-box
Indicates that a box outlining the area that would be filled with background color by an ImageText request should be displayed.
-center
Indicates that each glyph should be centered in its grid.
Specifies that character number char_num should be the first character displayed. (It appears in the upper left-hand corner of the grid.) This option is used to view characters at arbitrary locations in the font. The default is 0.
-bc color
Specifies the color to be used if ImageText boxes are drawn.
Resources
The Release 4 version of xfd was written with the X Toolkit Intrinsics. xfd accepts the following resources, which are accepted by most applications written with the Toolkit:
background (class Background)
Specifies the color to use for the window background.
borderWidth (class BorderWidth)
Specifies the width in pixels of the window border.
borderColor (class BorderColor)
Specifies the color to use for the window border.
foreground (class Foreground)
Specifies the color to use for text and graphics within the window.
Bugs
xfd should skip over pages full of non-existent characters.
See Also
X, xfontsel, xlsfonts, xrdb.
Author
Jim Fulton, MIT X Consortium.
xfontsel Preview and Select Fonts
Name
xfontsel – point-and-click interface for selecting display font names.
Syntax
xfontsel [options]
Description
Available as of Release 4, xfontsel provides a simple way to display the fonts known to your X server, examine samples of each, and retrieve the X Logical Font Description (XLFD) full name for a font.
If -pattern is not specified, all fonts with XLFD 14-part names will be selectable. To work with only a subset of the fonts, specify -pattern followed by a partially or fully qualified font name. For example,
% xfontsel -pattern *medium*
will select the subset of fonts that contain the string medium somewhere in their font name. Be careful about escaping wildcard characters in your shell.
If -print is specified on the command line, the selected font specifier will be written to standard output when the quit button is activated. Regardless of whether or not -print was specified, the font specifier may be made the (text) selection by activating the select button.
Clicking any pointer button in one of the XLFD field names will pop up a menu of the currently-known possibilities for that field. If previous choices of other fields were made, only values for fonts which matched the previously selected fields will be selectable; to make other values selectable, you must deselect some other field(s) by choosing the “*” entry in that field. Unselectable values may be omitted from the menu entirely as a configuration option; see the ShowUnselectable resource, below. Whenever any change is made to a field value, xfontsel will assert ownership of the PRIMARY_FONT selection. Other applications (such as xterm) may then retrieve the selected font specification.
Clicking the left pointer button in the select widget will cause the currently selected font name to become the PRIMARY text selection as well as the PRIMARY_FONT selection. Then you can paste the string into other applications. The select button remains highlighted to remind you of this fact, and de-highlights when some other application takes the PRIMARY selection away. The select widget is a toggle; pressing it when it is highlighted will cause xfontsel to release the selection ownership and de-highlight the widget. Activating the select widget twice is the only way to cause xfontsel to release the PRIMARY_FONT selection.
Options
xfontsel accepts all of the standard X Toolkit command line options, which are listed on the X reference page. In addition, xfontsel accepts the following application-specific options:
pattern fontname)
Specifies a subset of the available fonts, those with names that contain fontname, which can be a partial or full name.
print)
Specifies that the selected font will be written to standard output when the quit button is activated.
sample text)
Specifies the sample text to be used to display the selected font, overriding the default (the lowercase and uppercase alphabets and the digits 0 through 9).
Resources
The application class is XFontSel. Most of the user-interface is configured in the app-defaults file; if this file is missing, a warning message will be printed to standard output and the resulting window will be nearly incomprehensible.
Most of the significant parts of the widget hierarchy are documented in the app-defaults file (normally /usr/lib/X11/app-defaults/XFontSel).
Application specific resources: Specifies the cursor for the application window.
pattern (class Pattern)
Specifies the font name pattern for selecting a subset of available fonts. Equivalent to the -pattern option. Most useful patterns will contain at least one field delimiter, for example, *-m-* for monospaced fonts.
printOnQuit (class PrintOnQuit)
If True, the currently selected font name is printed to standard output when the quit button is activated. Equivalent to the -print option.
Widget-specific resources:
showUnselectable (class ShowUnselectable)
For each field menu, specifies whether or not to show values that are not currently selectable, based upon previous field selections. If shown, the unselectable values are clearly identified as such and do not highlight when the pointer is moved down the menu. The full instance name of this resource is fieldN.menu.options.showUnselectable, class MenuButton.SimpleMenu.Options.ShowUnselectable; where N is replaced with the field number (starting with the leftmost field numbered 0). The default is True for all but field 11 (average width of characters in font) and False for field 11. If you never want to see unselectable entries, *menu.options.showUnselectable: False is a reasonable thing to specify in a resource file.
Files
/usr/lib/X11/app-defaults/XFontSel—Specifies default resources.
See Also
xrdb.
Bugs
Sufficiently ambiguous patterns can be misinterpreted and can lead to an initial selection string which may not correspond to what the user intended and which may cause the initial sample text output to fail to match the proffered string. Selecting any new field value will correct the sample output, though possibly resulting in no matching font.
Should be able to return a font for the PRIMARY selection, not just a string.
Any change in a field value will cause xfontsel to assert ownership of the PRIMARY_FONT selection. Perhaps this should be parameterized.
When running on a slow machine, it is possible for the user to request a field menu before the font names have been completely parsed. An error message indicating a missing menu is printed to standard error, but otherwise nothing happens.
Author
Ralph R. Swick, Digital Equipment Corporation/MIT Project Athena.
xhost Server Access Control
Name
xhost – server access control program for X.
Syntax
xhost [options]
Description
The xhost program is used to add and delete hosts to and from the list of machines that are allowed to make connections to the X server. This provides a rudimentary form of privacy control and security. It is only sufficient for a workstation (single user) environment, although it does limit the worst abuses. Environments that require more sophisticated measures should use the hooks in the protocol for passing authentication data to the server.
The server initially allows network connections only from programs running on the same machine or from machines listed in the file /etc/Xn.hosts (where n is the display number of the server). The xhost program is usually run either from a startup file or interactively to give access to other users.
Hostnames that are followed by two colons (::) are used in checking DECnet connections; all other hostnames are used for TCP/IP connections.
If no command line options are given, the list of hosts that are allowed to connect is printed on the standard output along with a message indicating whether or not access control is currently enabled. This is the only option that may be used from machines other than the one on which the server is running.
Options
xhost accepts the command line options described below. For security, the options that affect access control may only be run from the same machine as the server.
[+]hostname
The given hostname (the plus sign is optional) is added to the list of machines that are allowed to connect to the X server.
-hostname
The given hostname is removed from the list of machines that are allowed to connect to the server. Existing connections are not broken, but new connection attempts will be denied. Note that the current machine is allowed to be removed; however, further connections (including attempts to add it back) will not be permitted. Resetting the server (thereby breaking all connections) is the only way to allow local connections again.
+
Access is granted to everyone, even if they aren't on the list of allowed hosts (i.e., access control is turned off).
−
Access is restricted to only those machines on the list of allowed hosts (i.e., access control is turned on).
Files
Bugs
You can't specify a display on the command line because -display indicates that you want to remove the machine named display from the access list.
See Also
X, Xserver, xauth.
Authors
Bob Scheifler, MIT Laboratory for Computer Science;
Jim Gettys, MIT Project Athena (DEC).
xinit Window System Initializer
Name
xinit – X Window System initializer.
Syntax
xinit [[client]options] [--[server_program] [-display [host]: server[.screen]] options]
Description
The xinit program is used to start the X Window System server program and a first client program (usually a terminal emulator) on systems that cannot start X directly from /etc/init or in environments that use multiple window systems. When this first client exits, xinit will kill the X server program and then terminate.
If no specific client program is given on the command line, xinit will look in the user's home directory for a file called .xinitrc to run as a shell script to start up other client programs. If no such file exists, xinit will use the following xterm command line as a default:
xterm -geometry +1+1 -n login -display :0
If no specific server program is given on the command line, xinit will look in the user's home directory for a file called .xserverrc to run as a shell script to start up the server. If no such file exists, xinit will use the following as a default server specification:
X :0
Note that this assumes that there is a server program called X in the current search path. However, servers are usually named Xdisplaytype, where displaytype is the type of graphics display which is driven by the server (for example, Xsun). The site administrator should therefore make a link to the appropriate type of server on the machine (see Chapter 2, Getting Started, in Part One of this guide for details), or create a shell script that runs xinit with the appropriate server.
Note that programs run by .xinitrc and by .xserverrc should be run in the background if they do not exit right away, so that they don't prevent other programs from starting up. However, the last long-lived program started (usually a window manager or terminal emulator) should be left in the foreground so that the script won't exit (which indicates that the user is done and that xinit should exit).
An alternate client and/or server may also be specified on the command line. The desired client program and its arguments should be given as the first command line arguments to xinit. To specify a particular server program, append a double dash (--) to the xinit command line (after any client and arguments) followed by the desired server program.
Both the client program name and the server program name must begin with a slash (/) or a period (.); otherwise, they are treated as arguments to be appended to their respective startup lines. This makes it possible to add arguments (for example, foreground and background colors) without having to retype the whole command line.
If an explicit server name is not given and the first argument following the double dash (--) is a colon followed by a digit, xinit will use that number as the display number instead of zero. All remaining arguments are appended to the server command line.
Note that you can start X manually by running xinit from the command line or start it automatically by adding the xinit command line to your .login or .profile file. (See Appendix A, System Management, for more information.)
Options
xinit accepts the following options:
client
Specifies the client to be started with the server.
server_program
Specifies the server program to be used.
-display [host]:server[.screen]
Specifies the host, server and screen on which you are initializing the X Window System. For example,
xinit -display your_node:0.1
specifies screen 1 on server 0 on the machine your_node. If the host is omitted, the local machine is assumed. If the screen is omitted, the screen 0 is assumed; the server and colon (:) are necessary in any case.
Examples
xinit
Will start up a server named X and run the user's .xinitrc, if it exists, or else start an xterm.
xinit -- /usr/bin/X11/Xqdss :1
Is how one could start a specific type of server on an alternate display.
xinit -geometry 80x65+10+10 -fn 8x13 -j -fg white -bg navy
Will start up a server named X, and will append the given arguments to the default xterm command. It will ignore .xinitrc.
xinit -e widgets -- Xsun -l -c
Will use the command ./Xsun -l -c to start the server and will append the arguments -e widgets to the default xterm command.
xinit rsh fasthost cpupig -display workstation: 1 -- 1 -a 2 -t 5
Will start a server named X on display 1 with the arguments -a 2 -t 5. It will then start a remote shell on the machine fasthost in which it will run the command cpupig, telling it to display back on the local workstation.
Below is a sample .xinitrc that starts a clock, several terminals, and leaves the window manager running as the “last” application. Assuming that the window manager has been configured properly, the user then chooses the Exit menu item to shut down X.
xrdb -load $HOME/.Xres xsetroot -solid grey & xclock -g 50x50−0+0 -bw 0 & xload -g 50x50−50+0 -bw 0 & xterm -g 80x24+0+0 & xterm -g 80x24+0−0 & twm
Sites that want to create a common startup environment could simply create a default .xinitrc that references a site-wide startup file:
#!/bin/sh ./usr/local/lib/site.xinitrc
Another approach is to write a script that starts xinit with a specific shell script. Such scripts are usually named x11, xstart, or startx and are a convenient way to provide a simple interface for novice users:
#!/bin/sh ./xinit/usr/local/bin/startx -- /usr/bin/X11/Xhp :1
Environment Variables
XINITRC
Specifies an init file containing shell commands to start up the initial windows. By default, .xinitrc in the home directory will be used.
See Also
X, Xserver, xterm.
Author
Bob Scheifler, MIT Laboratory for Computer Science.
xkill Kill a Client
Name
xkill – kill a client by its X resource.
Syntax
xkill [options]
Description
xkill is a utility for forcing the X server to close connections to clients. This program is very dangerous, but is useful for aborting programs that have displayed undesired windows on a user's screen. If no resource identifier is given with -id, xkill will display a special cursor as a prompt for the user to select a window to be killed. If a pointer button is pressed over a non-root window, the server will close its connection to the client that created the window.
Options
xkill accepts the following specific options:
-id resource
Specifies the X identifier for the resource whose creator is to be aborted. If no resource is specified, xkill will display a special cursor with which you should select a window to be killed.
-button number
-button any
Specifies the number of the pointer button that should be used to select the window to kill. If the word any is specified, any button on the pointer can be used. By default, the first button in the pointer map (which is usually the leftmost button) is used.
-all
Indicates that all clients with top-level windows on the screen should be killed. xkill will ask you to select the root window with each of the currently defined buttons to give you several chances to abort. Use of this option is highly discouraged.
-frame
Indicates that xkill should ignore the standard conventions for finding top-level client windows (which are typically nested inside a window manager window), and simply believe that you want to kill direct children of the root. (Available as of Release 4.)
-display [host]:server[.screen]
Allows you to specify the host, server, and screen to connect to. host specifies the machine, server specifies the server number, and screen specifies the screen number. For example,
xkill -display your_node:0.1
specifies screen 1 of server 0 on the machine your_node. Either or both the host and screen elements to the display specification can be omitted. If host is omitted, the local machine is assumed. If screen is omitted, screen 0 is assumed (and the period is unnecessary). The colon and server are necessary in all cases.
Resources
xkill defines the following application resource:
Button
Specifies a pointer button number to use when selecting the window to be removed. If the word any is specified, any button on the pointer can be used.
ee Also
X, xwininfo; Volume One, Xlib Programming Manual.
Author
Jim Fulton, MIT X Consortium;
Dana Chee, Bellcore.
xload Display Load Average
Name
xload – display system load average.
Syntax
xload [options]
Description
The xload program displays a periodically updating histogram of the system load average.
Options
xload accepts all of the standard X Toolkit command line options, which are listed on the X reference page. (We've included some of the more commonly used Toolkit options later in this section.) In addition, xload accepts the following application-specific options:
-scale integer
Specifies the minimum number of tick marks in the histogram, where one division represents one load average point. If the load goes above this number, xload will create more divisions, but it will never use fewer than this number. The default is 1.
-update seconds
Specifies the frequency in seconds at which xload updates its display. If the load average window is uncovered (by moving windows with a window manager or by the xrefresh program), the graph will also be updated. In Release 4, the minimum amount of time allowed between updates is 1 second (the default is 5 seconds). In Release 3, the minimum amount of time allowed between updates is 5 seconds (which is also the default).
-h1 color or
-highlight color
Specifies the color of the scale lines in Release 4. (Specifies the color of the label and scale lines in Release 3.)
-jumpscroll pixels
Specifies the number of pixels to shift the graph to the left when the graph reaches the right edge of the window. The default value is 1/2 the width of the current window. Smooth scrolling can be achieved by setting it to 1. (Available as of Release 4.)
-label string
Specifies the text string for the label above the load average. (Available as of Release 4.)
-nolabel
Specifies that no label be displayed above the load graph. (Available as of Release 4.)
The following standard X Toolkit options are commonly used with xload:
-bd color
Specifies the border color. The default is black.
-bg color
Specifies the background color. The default is white.
Specifies the width in pixels of the border around the window. The default is 2.
-fg color
Specifies the graph color. The default is black.
-fn fontname
Specifies the font to be used in displaying the name of the host whose load is being monitored. The default is the 6x10 pixel, fixed-width font “fixed”.
-rv
Indicates that reverse video should be simulated by swapping the foreground and background colors.
-geometry geometry
Specifies the size and location of the window. The -geometry option can be (and often is) abbreviated to -g, unless there is a conflicting option that begins with “g.” The argument to the geometry option (geometry) is referred to as a “standard geometry string,” and has the form widthxheight±xoff±yoff.
-display [host]:server[.screen]
Allows you to specify the host, server, and screen on which to create the xload window. See “Options” on the X reference page for an example of usage.
-xrm resourcestring
Specifies a resource string to be used. This is especially useful for setting resources that do not have separate command line options.
Resources
In addition to the resources available to each of the widgets used by xload, there is one resource defined by the application itself.
showLabel (class Boolean)
If False, then no label will be displayed.
Widget Hierarchy
In order to specify resources, it is useful to know the hierarchy of the widgets that compose xload. In the notation below, indentation indicates hierarchical structure. The widget class name is given first, followed by the widget instance name.
XLoad xload
Paned paned
Label label
StripChart load
See Appendix G, Athena Widget Resources for a list of resources that can be set for the Athena widgets.
See Also
X, xrdb, mem(4), Appendix G, Athena Widget Resources.
Diagnostics
Unable to open display or create window. Unable to open /dev/kmem. Unable to query window for dimensions. Various X errors.
Bugs
This program requires the ability to open and read /dev/kmem. Sites that do not allow general access to this file should make xload belong to the same group as /dev/kmem and turn on the set group id permission flag.
Reading /dev/kmem is inherently non-portable. Therefore, the routine used to read it (get_load.c) must be ported to each new operating system.
Border color has to be explicitly specified when reverse video is used.
Authors
K. Shane Hartman (MIT-LCS) and Stuart A. Malone (MIT-LCS);
with features added by Jim Gettys (MIT-Athena), Bob Scheifler (MIT-LCS), Tony Della Fera (MIT-Athena), and Chris Peterson (MIT-LCS).
xlogo X Window System Logo
Name
Synopsis
xlogo [options]
Description
The xlogo program displays the X Window System logo. This program is nothing more than a wrapper around the undocumented Athena Logo widget.
Options
xlogo accepts all of the standard X Toolkit command line options, which are listed on the X reference page. The following Toolkit options are commonly used:
-bg color
Specifies the color to use for the background of the window. The default is white. A correct color for the background is something like maroon.
-bd color
Specifies the color to use for the border of the window. The default is black.
-bw pixels
Specifies the width in pixels of the border surrounding the window.
-fg color
Specifies the color to use for displaying the logo. The default is black. A correct color for the foreground is something like silver, which you can approximate with a shade of grey.
-rv
Indicates that reverse video should be simulated by swapping the foreground and background colors.
-geometry geometry
The xlogo window is created with the specified size and location determined by the supplied geometry specification. The -geometry option can be (and often is) abbreviated to -g, unless there is a conflicting option that begins with “g.” The argument to the geometry option (geometry) is referred to as a “standard geometry string,” and has the form widthxheight±xoff±yoff.
display [host]:server[.screen]
Allows you to specify the host, server and screen on which to create the xlogo window. See “Options” on the X reference page for an example of usage.
-xrm resourcestring
Specifies a resource string to be used. This is especially useful for setting resources that do not have separate command line options.
Resources
This program uses the Logo widget in the Athena Widget Set. It understands all of the Core resource names and classes. The following resources are commonly used:
width (class Width)
Specifies the width of the logo.
height (class Height)
Specifies the height of the logo.
foreground (class Foreground)
Specifies the foreground color for the logo. The default depends on whether reverseVideo is specified. If reverseVideo is specified, the default is white; otherwise, the default is black.
reverseVideo (class ReverseVideo)
Specifies that the foreground and background should be reversed.
Widget Hierarchy
In order to specify resources, it is useful to know the hierarchy of the widgets that compose xlogo. In the notation below, indentation indicates hierarchical structure. The widget class name is given first, followed by the widget instance name.
XLogo xlogo
Logo xlogo
Files
/usr/lib/X11/app-defaults/XLogo—specifies required resources (as of Release 4).
See Also
X, xrdb.
Authors
Ollie Jones of Apollo Computer and Jim Fulton of the X Consortium wrote the logo graphics routine, based on a graphic design by Danny Chong and Ross Chapman of Apollo Computer.
xlsatoms List Interned Atoms
Name
xlsatoms – list interned atoms defined on the server.
Syntax
xlsatoms [options]
Description
Available as of Release 4, xlsatoms lists the interned atoms. By default, all atoms starting from 1 (the lowest atom value defined by the protocol) are listed until an unknown atom is found. If an explicit range is given, xlsatoms will try all atoms in the range, regardless of whether or not any are undefined.
Options
xlsatoms accepts the following options:
-format printf_string
Specifies a printf-style string used to list each atom <value, name> pair, printed in that order (value is an unsigned long and name is a char *). xlsatoms will supply a newline at the end of each line. The default is %ld %s.
-range [low]-[high]
Specifies the range of atom values to check. If low is not given, a value of 1 assumed. If high is not given, xlsatoms will stop at the first undefined atom at or above low.
-name string
Specifies the name of an atom to list. If the atom does not exist, a message will be printed on the standard error.
-display [host]:server[.screen]
Allows you to specify the host, server, and screen to connect to. host specifies the machine, server specifies the server number, and screen specifies the screen number. For example,
xlsatoms -display your_node: 0.1
specifies screen 1 of server 0 on the machine your_node. Either or both the host and screen elements can be omitted. If host is omitted, the local machine is assumed. If screen is omitted, screen 0 is assumed (and the period is unnecessary). The colon and server are necessary in all cases.
See Also
X, Xserver, xprop.
Author
Jim Fulton, MIT X Consortium.
xlsclients List Running Clients
Name
xlsclients – list client applications running on a display.
Syntax
xlsclients [options]
Description
Available as of Release 4, xlsclients is a utility for listing information about the client applications running on a display. It may be used to generate scripts representing a snapshot of the user's current session.
Options
xlsclients accepts the following options:
-a
Specifies that clients on all screens should be listed. By default, only those clients on the default screen are listed.
-l
Requests a long listing showing the window name, icon name, and class hints in addition to the machine name and command string in the default listing.
-m maxcmdlength
Specifies the maximum number of characters in a command to list. The default is 1000.
-display [host]:server[.screen]
Allows you to specify the host, server, and screen to connect to. host specifies the machine, server specifies the server number, and screen specifies the screen number. For example,
xlsclients -display your_node:0.1
specifies screen 1 of server 0 on the machine your_node. Either or both the host and screen can be omitted. If host is omitted, the local machine is assumed. If screen is omitted, screen 0 is assumed (and the period is unnecessary). The colon and server are necessary in all cases.
See Also
X, xprop, xwininfo.
Author
Jim Fulton, MIT X Consortium.
xlsfonts List Available Fonts
Name
xlsfonts – list available fonts.
Syntax
xlsfonts [options] [-fn pattern]
Description
xlsfonts lists the fonts that match the given pattern. The wildcard character “*” may be used to match any sequence of characters (including none), and “?” to match any single character. If no pattern is given, “*” is assumed.
The “*” and “?” characters must be quoted to prevent them from being expanded by the shell.
Options
xlsfonts accepts the following options:
-fn pattern
Indicates that only fonts matching the specified pattern be listed.
-l[l[l]]
Indicates that medium, long, and very long listings, respectively, should be generated for each font.
-m
Indicates that long listings should also print the minimum and maximum bounds of each font.
-C
Indicates that listings should use multiple columns. This is the same as -n 0.
-1
Indicates that listings should use a single column. This is the same as -n 1.
-w width
Specifies the width in characters that should be used in figuring out how many columns to print. The default is 79.
-n columns
Specifies the number of columns to use in displaying the output. By default, it will attempt to fit as many columns of font names as possible into the number of characters specified by -w width.
-display [host]:server[.screen]
Allows you to specify the host, server, and screen. For example,
xlsfonts -display your_node:0.1
specifies screen 1 on server 0 on the machine your_node. If the host is omitted, the local machine is assumed. If the screen is omitted, the screen 0 is assumed; the server and colon are necessary in all cases.
See Also
X, Xserver, xset, xfd, xfontsel.
Bugs
Doing xlsfonts −l can tie up your server for a very long time. This is really a bug with single-threaded, non-preemptable servers, not with this program.
Author
Mark Lillibridge, MIT Project Athena;
Jim Fulton, MIT X Consortium;
Phil Karlton, SGI.
xlswins List Window Tree
Name
xlswins – server window list displayer for X.
Syntax
xlswins [options] [window_id]
Description
xlswins lists the window tree. By default, the root window is used as the starting point, although another window may be specified using the window_id option.
Options
xlswins accepts the following options:
-l
Indicates that a long listing should be generated for each window. This includes a number indicating the depth, the geometry relative to the parent, and the location relative to the root window.
-format radix
Specifies the radix to use when printing out window IDs. Allowable values are: hex, octal, and decimal. The default is hex.
-indent number
Specifies the number of spaces that should be indented for each level in the window tree. The default is 2.
window_id
Specifies that the starting point for the window tree listing is the window window_id.
-display [host]:server[.screen]
Allows you to specify the host, server, and screen to connect to host specifies the machine, server specifies the server number, and screen specifies the screen number. For example,
xlswins -display your_node:0.1
specifies screen 1 of server 0 on the machine your_node. Either or both the host and screen elements can be omitted. If host is omitted, the local machine is assumed. If screen is omitted, screen 0 is assumed (and the period is unnecessary). The colon and server are necessary in all cases.
See Also
X, Xserver, xwininfo, xprop.
Bugs
This should be integrated with xwininfo somehow.
Author
Jim Fulton, MIT X Consortium.
xmag Magnify Screen Portions
Name
xmag — magnify parts of the screen.
Syntax
xmag [options]
Description
The xmag program allows you to magnify portions of the screen. If no explicit region is specified, a square centered around the pointer is displayed indicating the area to be enlarged. Once a region has been selected, a window is popped up showing a blown up version of the region in which each pixel in the source image is represented by a small square of the same color. Pressing Button1 on the pointer in the enlargement window pops up a small window displaying the position, number, and RGB value of the pixel under the pointer until the button is released, Pressing the space bar or any other pointer button removes the enlarged image so that another region may be selected. Pressing Q, or Control-C in the enlargement window exits the program.
Options
xmag accepts all of the standard X Toolkit command line options, which are listed on the X reference page. (We've included some of the more commonly used Toolkit options later in this section.) In addition, xmag accepts the following application-specific options:
-source geometry
This option specifies the size and/or location of the source region on the screen. By default, a 64x64 square centered about the pointer is provided for the user to select an area of the screen. The size of the source is used with the desired magnification to compute the default enlargement window size. Therefore, only one of -geometry size and -mag magfactor options may be specified if a source size is given with this option.
-mag magfactor
This option specifies an integral factor by which the source region should be enlarged. The default magnification is 5. This is used with the size of the source to compute the default enlargement window size. Therefore, only one of -geometry size and -source geometry options may be specified if a magnification factor is given with this option.
-z
This option indicates that the server should be grabbed during the dynamics and the call to XGetImage. This is useful for ensuring that clients don't change their state as a result of entering or leaving them with the pointer.
The following standard X Toolkit options are commonly used with xmag:
-display [host]:server[.screen]
Allows you to specify the host, server and screen to use for both reading the screen and displaying the enlarged version of the image. host specifies the machine, server specifies the server number, and screen specifies the screen number. For example:
specifies screen 1 of server 0 on the machine your_node. Either or both the host and screen elements to the display specification can be omitted. If host is omitted, the local machine is assumed. If screen is omitted, screen 0 is assumed (and the period is unnecessary). The colon and server are necessary in all cases.
-geometry geometry
The enlargement window is created with the specified size and location determined by the supplied geometry specification. The -geometry option can be (and often is) abbreviated to -g, unless there is a conflicting option that begins with “g.” The argument to the geometry option (geometry) is referred to as a “standard geometry string,” and has the form widthxheight±xoff±yoff.
By default, the size is computed from the size of the source region and the desired magnification. Therefore, only one of -source size and -mag magfactor options may be specified if a window size is given with the -geometry option.
-bw pixels
This option specifies the width in pixels of the border surrounding the enlargement window.
-bd color
This option specifies the color to use for the border surrounding the enlargement window.
-bg color_or_pixel_value
This option specifies the name of the color to be used as the background of the enlargement window. If the name begins with a percent size (%), it is interpreted to be an absolute pixel value. This is useful when displaying large areas, since pixels that are the same color as the background do not need to be painted in the enlargement. The default is to use the BlackPixel of the screen.
-fn fontname
This option specifies the name of a font to use when displaying pixel values (used when button 1 is pressed in the enlargement window).
Resources
The xmag program defines the following application resources:
source (class Source)
Specifies the size and/or location of the source region on the screen.
magnification (class Magnification)
Specifies the enlargement factor.
xmag also understands the Core X Toolkit resources, of which the following are commonly used:
geometry (class Geometry)
Specifies the size and/or location of the enlargement window.
borderWidth (class BorderWidth)
Specifies the border width in pixels.
borderColor (class BorderColor)
Specifies the color of the border.
background (class Background)
Specifies the color or pixel value to be used for the background of the enlargement window.
font (class Font)
Specifies the name of the font to use when displaying pixel values when the user presses button 1 in the enlargement window.
See Also
X, xwd.
Bugs
This program will behave strangely on displays that support windows of different depths.
Because the window size equals the source size times the magnification, you need to specify only two of the three parameters. This can be confusing.
Being able to drag the pointer around and see a dynamic display would be very nice.
Another possible interface would be for the user to drag out the desired area to be enlarged.
Author
Jim Fulton, MIT X Consortium.
xman Display Man Pages
Name
Syntax
xman [options]
Description
xman is a manual page browser. The default size of the initial xman window is small so that you can leave it running throughout your entire login session. In the initial window there are three options: Help will pop up a window with online help, Quit will exit, and Manual Page will pop up a window with a manual page browser in it. You may pop up more than one manual page browser window from a single execution of xman.
For further information on using xman, please read the online help information. The rest of this manual page will discuss customization of xman.
Customization
xman allows customization of both the directories to be searched for manual pages, and the name that each directory will map to in the Sections menu. xman determines which directories it will search by reading the MANPATH environment variable. If no MANPATH is found then the directory /usr/man is searched on POSIX systems. This environment is expected to be a colon-separated list of directories for xman to search.
setenv MANPATH /mit/kit/man:/usr/man
By default, xman will search each of the following directories (in each of the directories specified in the users MANPATH) for manual pages. If manual pages exist in that directory, then they are added to the list of manual pages for the corresponding menu item. A menu item is only displayed only for those sections that actually contain manual pages.
| Directory | Section Name |
| man1 | (1) User Commands |
| man2 | (2) System Calls |
| man3 | (3) Subroutines |
| man4 | (4) Devices |
| man5 | (5) File Formats |
| man6 | (6) Games |
| man7 | (7) Miscellaneous |
| man8 | (8) Sys. Administration |
| manl | (l) Local |
| mann | (n) New |
| mano | (o) Old |
For instance, a user has three directories in her manual path and each contains a directory called man3. All these manual pages will appear, alphabetically sorted, when the user selects the menu item called (3) Subroutines. If there is no directory called mano in any of the directories in her MANPATH, or there are no manual pages in any of the directories called mano, then no menu item will be displayed for the section called (o) Old.
By using the mandesc file, a user or system manager is able to more closely control which manual pages will appear in each of the sections represented by menu items in the Sections menu. This functionality is available only on a section-by-section basis, and individual manual pages may not be handled in this manner (although generous use of symbolic links, ln(1), will allow almost any configuration you can imagine).
The format of the mandesc file is a character followed by a label. The character determines which of the sections will be added under this label. For instance, suppose that you would like to create an extra menu item that contains all programmer subroutines. This label should contain all manual pages in both sections two and three. The mandesc file would look like this:
2Programmer Subroutines 3Programmer Subroutines
This will add a menu item to the Sections menu that would bring up a listing of all manual pages in sections two and three of the UNIX Programmer's Manual. Since the label names are exactly the same, they will be added to the same section. Note, however, that the original sections still exist.
If you want to completely ignore the default sections in a manual directory, then add the line:
no default sections
anywhere in your mandesc file. This keeps xman from searching the default manual sections in that directory only. As an example, suppose you want to do the same thing as above, but you don't think that it is useful to have the System Calls or Subroutines sections any longer. You would need to duplicate the default entries, as well as adding your new one.
no default sections 1(1) User Commands 2Programmer Subroutines 3Programmer Subroutines 4(4) Devices 5(5) File Formats 6(6) Games 7(7) Miscellaneous 8(8) Sys. Administration l(l) Local n(n) New o(o) Old
xman will read any section that is of the form man<character>, where <character> is an uppercase or lowercase letter (they are treated distinctly) or a numeral (0-9). Be warned, however, that man(1) and catman(8) will not search directories that are non-standard.
Options
xman accepts all of the standard X Toolkit command line options, which are listed on the X reference page. (We've included some of the more commonly used Toolkit options later in this section.) In addition, xman accepts the following application-specific options:
-helpfile filename
Specifies a helpfile to use other than the default.
-bothshown
Allows both the manual page and manual directory to be on the screen at the same time.
-notopbox
Starts without the top menu with the three buttons in it.
-pagesize geometry
Sets the size and location of all the manual pages.
The following X Toolkit options are commonly used with xman:
-geometry geometry
Sets the size and location of the top menu with the three buttons in it. This menu is created with the specified size and location determined by the supplied geometry specification. The -geometry option can be (and often is) abbreviated to -g, unless there is a conflicting option that begins with “g.” The argument to the geometry option (geometry) is referred to as a “standard geometry string,” and has the form widthxheight±xoff±yoff.
-display [host]:server[.screen]
Allows you to specify the host, server, and screen on which to display the xman window See “Options” on the X reference page for an example of usage.
-bw pixels or -borderwidth pixels
Specifies the width of the border for all windows in xman.
-bd color or -bordercolor color
Specifies the color of the borders of all windows in xman.
-fg color or -foreground color
Specifies the foreground color to be used.
-bg color or -background color
Specifies the background color to be used.
-fn font or -font font
Specifies the font to use for all buttons and labels.
-name name
Specifies the name to use when retrieving resources.
-title title
Specifies the title of this application.
Allows a resource to be specified on the command line.
Resources
The xman program uses the following X Toolkit resources: foreground, background, width, height, borderWidth, and borderColor.
In addition, xman has application-specific resources that allow unique xman customizations.
manualFontNormal (class Font)
The font to use for normal text in the manual pages.
manualFontBold (class Font)
The font to use for bold text in the manual pages.
manualFontItalic (class Font)
The font to use for italic text in the manual pages.
directoryFontNormal (class Font)
The font to use for the directory text.
bothShown (class Boolean)
Either True or False, specifies whether or not you want both the directory and the manual page shown at startup.
directoryHeight (class DirectoryHeight)
The height in pixels of the directory, when the directory and the manual page are shown simultaneously.
topCursor (class Cursor)
The cursor to use in the top box.
helpCursor (class Cursor)
The cursor to use in the help window.
manpageCursor (class Cursor)
The cursor to use in the manual page window.
searchEntryCursor (class Cursor)
The cursor to use in the search entry text widget.
pointerColor (class Foreground)
The color of all the cursors (pointers) listed above. The name was chosen to be compatible with xterm. (Available as of Release 4.)
helpFile (class File)
Use this rather than the system default helpfile.
topBox (class Boolean)
Either True or False, determines whether the top box (containing the Help, Quit, and Manual Page buttons) or a manual page is put on the screen at startup. The default is True.
Either True or False, determines whether the directory listing is vertically or horizontally organized. The default is horizontal (False).
Widget Hierarchy
In order to specify resources, it is useful to know the hierarchy of the widgets that compose xman. In the notation below, indentation indicates hierarchical structure. The widget class name is given first, followed by the widget instance name.
Xman xman (This widget is never used) TopLevelShell topbox Form form Label topLabel Command helpButton Command quitButton Command manpageButton TransientShell search DialogWidgetClass dialog Label label Text value Command manualPage Command apropos Command cancel TransientShell pleaseStandBy Label label TopLevelShell manualBrowser Paned Manpage_Vpane Paned horizPane MenuButton options MenuButton sections Label manualBrowser Viewport directory List directory List directory . . (one for each section, . created “on the fly”) . ScrollByLine manualPage SimpleMenu optionMenu SmeBSB displayDirectory SmeBSB displayManualPage SmeBSB help SmeBSB search SmeBSB showBothScreens SmeBSB removeThisManpage SmeBSB openNewManpage SmeBSB showVersion SmeBSB quit SimpleMenu sectionMenu SmeBSB <name of section> . . (one for each section) . TransientShell search DialogWidgetClass dialog Label label Text value Command manualPage Command apropos Command cancel TransientShell pleaseStandBy Label label TransientShell likeToSave Dialog dialog Label label Text value Command yes Command no TopLevelShell help Paned Manpage_Vpane Paned horizPane MenuButton options MenuButton sections Label manualBrowser ScrollByLine manualPage SimpleMenu optionMenu SmeBSB displayDirectory SmeBSB displayManualPage SmeBSB help SmeBSB search SmeBSB showBothScreens SmeBSB removeThisManpage SmeBSB openNewManpage SmeBSB showVersion SmeBSB quit
See Appendix G, Athena Widget Resources, for a list of resources that can be set for the Athena widgets.
Global Actions
xman defines all user interaction through global actions. This allows the user to modify the translation table of any widget, and bind any event to the new user action. The list of actions supported by xman are:
GotoPage (page)
When used in a manual page display window, this action allows the user to move between a directory and manual page display. The page argument can be either Directory or ManualPage.
Can be used anywhere; exits xman.
Search (type, action)
Useful only when used in a search pop-up, this action will cause the search widget to perform the named search type on the string in the search popup's value widget. This action will also pop down the search widget. The type argument can be either Apropos, Manpage, or Cancel. If an action of Open is specified, then xman will open a new manual page to display the results of the search; otherwise, xman will attempt to display the results in the parent of the search popup.
PopupHelp()
Can be used anywhere; pops up the help widget.
PopupSearch()
Can be used anywhere, except in a help window. It will cause the search popup to become active and visible on the screen, allowing the user to search for a manual page.
CreateNewManpage()
Can be used anywhere; creates a new manual page display window.
RemoveThisManpage()
Can be used in any manual page or help display window. When called, it will remove the window and clean up all resources associated with it.
SaveFormattedPage(action)
Can be used only in the likeToSave popup widget, and tells xman whether to Save or Cancel a save of the manual page that has just been formatted.
ShowVersion()
May be called from any manual page or help display window, and will cause the informational display line to show the current version of xman.
Files
<manpath directory>/man<character> <manpath directory>/cat<character> <manpath directory>/mandesc /usr/lib/X11/app-defaults/Xman—Specifies required resources (as of Release 4). /tmp—xman creates temporary files in /tmp for all unformatted man pages and all apropos searches.
Environment Variables
MANPATH
The search path for manual pages. Directories are separated by colons (e.g., /usr/man:/mit/kit/man:/foo/bar/man).
A string that will have “Xman” appended to it. This string will be the full path name of a user app-defaults file to be merged into the resource database after the system app-defaults file, and before the resources that are attached to the display. (Available as of Release 4.)
See Also
X, apropos(1), catman(8), man(1), Appendix G, Athena Widget Resources.
Authors
Chris Peterson, MIT X Consortium, from the V10 version written by Barry Shein, formerly of Boston University.
xmh X Interface to mh
Name
xmh – X window interface to the mh message handling system.
Syntax
xmh [-path mailpath] [-initial foldername] [-flag] [-toolkitoption]
Description
xmh is a window-oriented user interface to the Rand mh Message Handling System. To actually do things with your mail, xmh makes calls to the mh package. Electronic mail messages may be composed, sent, received, replied to, forwarded, sorted, and stored in folders.
Please don't be misled by the size of this document. It introduces many aspects of the Athena widget set, and provides extensive mechanism for customization of the user interface. xmh really is easy to use.
Options
xmh accepts all of the standard X Toolkit command line options, which are listed on the X reference page. In addition, xmh accepts the following application-specific options:
-path mailpath
To specify an alternate collection of mail folders in which to process mail, use -path followed by the pathname of the alternate mail directory. The default mail path is the value of the Path component in $HOME/.mh_profile, or $HOME/Mail if the MH Path is not given.
-initial foldername
Specifies an alternate folder that may receive new mail and is initially opened by xmh. The default initial folder is inbox.
-flag
Causes xmh to attempt to change the appearance of its icon when new mail arrives.
These three options have corresponding application-specific resources, named MailPath, InitialFolder, and MailWaitingFlag, which can be used in a resource file.
Installation
The current version of xmh requires that the user is already set up to use mh, version 6. First, see if there is a file called .mh_profile in your home directory. If it exists, check to see if it contains a line that starts with Current-Folder. If it does, you've been using version 4 or earlier of mh; to convert to version 6, you must remove that line. (Failure to do so causes spurious output to standard error, which, depending on your setup, can hang xmh.)
If you do not already have an .mk_profile, you can create one (and everything else you need) by typing inc to the shell. You should do this before using xmh to incorporate new mail.
For more information, refer to the mh(1) documentation.
Basic Screen Layout
xmh starts out with a single window, divided into four main areas: Six buttons with pull-down command menus. A collection of buttons, one for each top level folder. New users of mh will have two folders, “drafts” and “inbox”. A listing, or Table of Contents, of the messages in the open folder. Initially, this will show the messages in “inbox”. A view of one of your messages. Initially this is blank.
xmh and the Athena Widget Set
xmh uses the X Toolkit Intrinsics and the Athena widget set. Many of the features described below (scrollbars, buttonboxes, etc.) are actually part of the Athena widget set, and are described here only for completeness. For more information, see Appendix G, Athena Widget Resources.
Scrollbars
Some parts of the main window will have a vertical area on the left containing a grey bar. This area is a scrollbar. They are used whenever the data in a window takes up more space than can be displayed. The grey bar indicates what portion of your data is visible. Thus, if the entire length of the area is grey, then you are looking at all your data. If only the first half is grey, then you are looking at the top half of your data. The message viewing area will have a horizontal scrollbar if the text of the message is wider than the viewing area.
You can use the pointer in the scrollbar to change what part of the data is visible. If you click with the middle button, then the top of the grey area will move to where the pointer is, and the corresponding portion of data will be displayed. If you hold down the middle button, you can drag around the grey area. This makes it easy to get to the top of the data: just press with the middle, drag off the top of the scrollbar, and release.
If you click with button 1, then the data to the right of the pointer will scroll to the top of the window. If you click with pointer button 3, then the data at the top of the window will scroll down to where the pointer is.
Buttonboxes, Buttons, and Menus
Any area containing many words or short phrases, each enclosed in a rectangle or rounded boundary, is called a buttonbox. Each rectangle or rounded area is actually a button that you can press by moving the pointer onto it and pressing pointer button 1. If a given buttonbox has more buttons in it than can fit, it will be displayed with a scrollbar, so you can always scroll to the button you want.
Some buttons have pull-down menus. Pressing the pointer button while the pointer is over one of these buttons will pull down a menu. Holding the button down while moving the pointer over the menu, called dragging the pointer, will highlight each selectable item on the menu as the pointer passes over it. To select an item in the menu, release the pointer button while the item is highlighted.
Adjusting the Relative Sizes of Areas
If you're not satisfied with the sizes of the various areas of the main window, they can easily be changed. Near the right edge of the border between each region is a black box, called a grip. Simply point to that grip with the pointer, press a pointer button, drag up or down, and release. Exactly what happens depends on which pointer button you press:
If you drag with the middle button, then only that border will move. This mode is simplest to understand, but is the least useful.
If you drag with pointer button 1, then you are adjusting the size of the window above. xmh will attempt to compensate by adjusting some window below it.
If you drag with pointer button 3, then you are adjusting the size of the window below. xmh will attempt to compensate by adjusting some window above it.
All windows have a minimum and maximum size; you will never be allowed to move a border past the point where it would make a window have an invalid size.
Processing Your Mail
This section will define the concepts of the selected folder, current folder, selected message(s), current message, selected sequence, and current sequence. Each xmh command is introduced.
For use in customization, action procedures corresponding to each command are given; these action procedures can be used to customize the user interface, particularly the keyboard accelerators and the functionality of the buttons in the optional buttonbox created by the application resource CommandButtonCount.
Selected Folder
A folder contains a collection of mail messages, or is empty.
The selected folder is whichever folder name appears in the bar above the folder buttons. Note that this is not necessarily the same folder that is being viewed. To change the selected folder, just press on the desired folder button; if that folder has subfolders, select a folder from the pull down menu.
The Table of Contents, or toc, lists the messages in the viewed folder. The title bar above the Table of Contents displays the name of the viewed folder.
The toc title bar also displays the name of the viewed sequence of messages within the viewed folder. Every folder has an “all” sequence, which contains all the messages in the folder, and initially the toc title bar will show “inbox:all”.
Folder Commands
The Folder command menu contains commands of a global nature:
Open Folder
Displays the data in the selected folder. Thus, the selected folder also becomes the viewed folder. The action procedure corresponding to this command is XmhOpenFolder ([foldername]). It takes an optional argument as the name of a folder to select and open; if no folder is specified, the selected folder is opened. It may be specified as part of an event translation from a folder menu button or from a folder menu, or as a binding of a keyboard accelerator to any widget other than the folder menu buttons or the folder menus.
Displays the selected folder in an additional main window. Note, however, that you may not reliably display the same folder in more than one window at a time, although xmh will not prevent you from trying. The corresponding action is XmhOpenFolderInNewWindow().
Create Folder
Creates a new folder. You will be prompted for a name for the new folder; to enter the name, move the pointer to the blank box provided and type. Subfolders are created by specifying the parent folder, a slash, and the subfolder name. For example, to create a folder named “xmh” which is a subfolder of an existing folder named “clients” type “clients/xmh”. Click on the Okay button when finished, or just press Return; click on Cancel to cancel this operation. The action corresponding to Create Folder is XmhCreateFolder().
Delete Folder
Destroys the selected folder. You will be asked to confirm this action (see “Confirmation Windows”). Destroying a folder will also destroy any subfolders of that folder. The corresponding action is XmhDeleteFolder().
Close Window
Exits xmh, after first confirming that you won't lose any changes; or, if selected from any additional xmh window, simply closes that window. The corresponding action is XmhClose().
Highlighted and Selected Messages and the Current Message
It is possible to highlight a set of adjacent messages in the area of the Table of Contents. To highlight a message, click on it with pointer button 1. To highlight a range of messages, click on the first one with pointer button 1 and on the last one with pointer button 3; or press pointer button 1, drag, and release. To extend a range of selected messages, use pointer button 3. To highlight all messages in the table of contents, click rapidly three times with pointer button 1. To cancel any selection in the table of contents, click rapidly twice.
The selected messages are the same as the highlighted messages, if any. If no messages are highlighted, then the selected messages are considered the same as the current message.
The current message is indicated by a “+” next to the message number. It usually corresponds to the message currently being viewed. When a message is viewed, the title bar above the view will identify the message.
Table of Contents Commands
The Table of Contents command menu contains commands which operate on the open, or viewed, folder.
Incorporate New Mail
Adds any new mail received to your inbox folder, and sets the current message to be the first new message. (This command is selectable only if “inbox” is the folder being viewed.) The corresponding action is XmhIncorporateNewMail().
Executes all deletions, moves, and copies that have been marked in this folder. The corresponding action is XmhCommitChanges().
Pack Folder
Renumbers the messages in this folder so they start with 1 and increment by 1. The corresponding action is XmhPackFolder().
Sort Folder
Sorts the messages in this folder in chronological order. As a side effect, this also packs the folder. The corresponding action is XmhSortFolder().
Rescan Folder
Rebuilds the list of messages. This can be used whenever you suspect that xmh's idea of what messages you have is wrong. (In particular, this is necessary if you change things using straight mh commands without using xmh.) The corresponding action is XmhForceRescan().
Message Commands
The Message command menu contains commands that operate on the selected message(s), or if there are no selected messages, the current message.
Compose Message
Composes a new message. A new window will be brought up for composition; a description of it is given in the “Composition Windows” section below. This command does not affect the current message. The corresponding action is XmhComposeMessage().
View Next Message
Views the first selected message. If no messages are highlighted, views the current message. If the current message is already being viewed, views the first unmarked message after the current message. The corresponding action is XmhViewNextMessage().
View Previous
Views the last selected message. If no messages are highlighted, views the current message. If current message is already being viewed, views the first unmarked message before the current message. The corresponding action is XmhViewPrevious().
Mark Deleted
Marks the selected messages for deletion. If no messages are highlighted, then this marks the current message for deletion and automatically displays the next unmarked message. The corresponding action is XmhMarkDeleted().
Mark Move
Marks the selected messages to be moved into the current (selected) folder. (If the current folder is the same as the viewed folder, this command will just beep.) If no messages are highlighted, this will mark the current message to be moved and display the next unmarked message. The corresponding action is XmhMarkMove().
Marks the selected messages to be copied into the current folder. (If the current folder is the same as the viewed folder, this command will just beep.) If no messages are highlighted, marks the current message to be copied. The corresponding action is XmhMarkCopy().
Unmark
Removes any of the above three marks from the selected messages, or the current message, if none is highlighted. The corresponding action is XmhUnmark().
View in New Window
Creates a new window containing only a view of the first selected message, or the current message, if none is highlighted. The corresponding action is XmhViewInNewWindow().
Reply
Creates a composition window in reply to the first selected message, or the current message, if none is highlighted. The corresponding action is XmhReply().
Forward
Creates a composition window whose body is initialized to be the contents of the selected messages, or the current message if none is highlighted. The corresponding action is XmhForward().
Use as Composition
Creates a composition window whose body is initialized to be the contents of the first selected message, or the current message if none is selected. Any changes you make in the composition will be saved in a new message in the “drafts” folder, and will not change the original message. However, this command was designed to be used within the “drafts” folder to compose message drafts, and there is an exception to this rule. If the message to be used as composition was selected from the “drafts” folder, the changes will be reflected in the original message (see “Composition Windows”). The action procedure corresponding to this command is XmhUseAsComposition().
Prints the selected messages, or the current message if none is selected. xmh normally prints by invoking the enscript(1) command, but this can be customized with the application-specific resource PrintCommand. The action procedure corresponding to this command is XmhPrint().
Sequence Commands
The Sequence command menu contains commands pertaining to message sequences (See “Message Sequences”), and a list of the message sequences defined for the currently viewed folder. The selected message sequence is indicated by a check mark in its entry in the margin of the menu. To change the selected message sequence, select a new message sequence from the sequence menu.
Pick Messages
Defines a new message sequence. The corresponding action is XmhPickMessages().
The following menu entries will be sensitive only if the current folder has any message sequences other than the “all” message sequence.
Changes the viewed sequence to be the same as the selected sequence. The corresponding action is XmhOpenSequence().
Add to Sequence
Adds the selected messages to the selected sequence. The corresponding action is XmhAddToSequence().
Remove from Sequence
Removes the selected messages from the selected sequence. The corresponding action is XmhRemoveFromSequence().
Delete Sequence
Removes the selected sequence entirely. The messages themselves are not affected; they are simply no longer grouped together to define a message sequence. The corresponding action is XmhDeleteSequence().
View Commands
Commands in the View menu and in the buttonboxes of view windows (which result from the Message command View in New Window) correspond in functionality to commands of the same name in the Message menu, but they operate on the viewed message rather than the selected messages or current message.
Close Window
When the viewed message is in a separate view window, this command will close the view, after confirming the status of any unsaved edits. The corresponding action procedure is XmhCloseView().
Reply
Creates a composition window in reply to the viewed message. The related action procedure is XmhViewReply().
Forward
Creates a composition window whose body is initialized to be the contents of the viewed message. The corresponding action is XmhViewForward().
Use As Composition
Creates a composition window whose body is initialized to be the contents of the viewed message. Any changes made in the composition window will be saved in a new message in the “drafts” folder, and will not change the original message. An exception: if the viewed message was selected from the “drafts” folder, the original message is edited. The action procedure corresponding to this command is XmhViewUseAsComposition().
Edit Message
Enables the direct editing of the viewed message. The action procedure is XmhEditView().
Save Message
This command is insensitive until the message has been edited; when activated, edits will be saved to the original message in the view. The corresponding action is XmhSaveView().
Prints the viewed message. xmh prints by invoking the enscript(1) command, but this can be customized with the application-specific resource PrintCommand. The corresponding action procedure is XmhPrintView().
Options Menu
The Options menu contains one entry.
Read in Reverse
When selected, a check mark appears in the margin of this menu entry. Read in Reverse will switch the meaning of the next and previous messages, and will increment in the opposite direction. This is useful if you want to read your messages in the order of most recent first. The option acts as a toggle; select it from the menu a second time to undo the effect. The check mark appears when the option is selected.
Composition Windows
Aside from the normal text editing functions, there are six command buttons associated with composition windows:
Close Window
Closes this composition window. If changes have been made since the most recent Save or Send, you will be asked to confirm losing them. The corresponding action is XmhCloseView().
Send
Sends this composition. The corresponding action is XmhSend().
New Headers
Replaces the current composition with an empty message. If changes have been made since the most recent Send or Save, you will be asked to confirm losing them. The corresponding action is XmhResetCompose().
Compose Message
Brings up another new composition window. The corresponding action is XmhComposeMessage().
Save Message
Saves this composition in your drafts folder. Then you can safely close the composition. At some future date, you can continue working on the composition by opening the drafts folder, selecting the message, and using the Use as Composition command. The corresponding action is XmhSave().
Insert
Inserts a related message into the composition. If the composition window was created with a Reply command, the related message is the message being replied to; otherwise, no related message is defined and this button is insensitive. The message may be filtered before being inserted; see ReplyInsertFilter under “Application-specific Resources” for more information. The corresponding action is XmhInsert().
Accelerators
Accelerators are shortcuts. They allow you to invoke commands without using the menus, either from the keyboard or by using the pointer.
xmh defines pointer accelerators for common actions: to select and view a message with a single click, use pointer button 2 on the message's entry in the table of contents; to select and open a folder or a sequence in a single action, make the folder or sequence selection with pointer button 2.
To mark the highlighted messages to be moved in a single action, or current message if none has been highlighted, use pointer button 3 to select the target folder. Similarly, selecting a sequence with pointer button 3 will add the highlighted or current message(s) to that sequence. In both of these operations, the selected folder or sequence and the viewed folder or sequence are not changed.
xmh defines the following keyboard accelerators over the surface of the main window, except in the view area while editing a message:
Meta-I
Incorporate new mail.
Meta-C
Commit changes.
Meta-R
Rescan folder.
Meta-P
Pack folder.
Meta-S
Sort folder.
Meta-space
View next message.
Meta-c
Mark copy.
Meta-d
Mark deleted.
Meta-f
Forward the selected or current message.
Meta-m
Mark move.
Meta-n
View next message.
Meta-p
View previous message.
Meta-r
Reply to the selected or current message.
Meta-u
Unmark.
Control-V
Scroll the table of contents forward.
Meta-V
Scroll the table of contents backward.
Control-v
Scroll the view forward.
Meta-v
Scroll the view backward.
Text Editing Commands
All of the text editing commands are actually defined by the Text widget in the Athena widget set. The commands may be bound to different keys than the defaults described below through the X Toolkit Intrinsics key re-binding mechanisms. See Chapter 10, Setting Resources, and Appendix G, Athena Widget Resources, for more details.
Whenever you are asked to enter any text, you will be using a standard text editing interface. Various control and meta keystroke combinations are bound to a somewhat Emacs-like set of commands. In addition, the pointer buttons may be used to select a portion of text or to move the insertion point in the text. Pressing pointer button 1 causes the insertion point to move to the pointer. Double-clicking button 1 selects a word, triple-clicking selects a line, quadruple-clicking selects a paragraph, and quintuple-clicking selects everything. Any selection may be extended in either direction by using pointer button 3.
In the following, a line refers to one displayed row of characters in the window, while a paragraph refers to the text between carriage returns. Text within a paragraph is broken into lines for display based on the current width of the window. When a message is sent, text is broken into lines based upon the values of the SendBreakWidth and SendWidth application-specific resources.
The following keystroke combinations are defined:
Control-a
Move to the beginning of the current line.
Control-b
Move backward one character.
Control-d
Delete the next character.
Control-e
Move to the end of the current line.
Control-f
Move forward one character.
Control-g
Multiply reset.
Control-h
Delete previous character.
Control-j
Create a new paragraph with the same indentation as the previous one.
Control-k
Kill the rest of the current line.
Control-l
Refresh the window.
Control-m
New paragraph.
Control-n
Move down to the next line.
Control-o
Break this paragraph into two.
Control-p
Move up to the previous line.
Control-r
Search/replace backward.
Control-s
Search/replace forward.
Control-t
Transpose characters.
Multiply by 4.
Control-v
Move down to the next screenful of text.
Control-w
Kill the selected text.
Control-y
Insert the last killed text.
Control-z
Scroll the text up one line.
Meta-B
Move backward one word.
Meta-d
Delete the next word.
Meta-D
Kill the next word.
Meta-f
Move forward one word.
Meta-h
Delete the previous word.
Meta-H
Kill the previous word.
Meta-i
Insert file.
Meta-k
Kill to end of paragraph.
Meta-q
Form paragraph.
Meta-v
Move up to the previous screenful of text.
Meta-y
Insert current text selection.
Meta-z
Scroll one line down.
Meta-<
Move to the beginning of the file.
Meta->
Move to the end of the file.
Meta-]
Move forward one paragraph.
Meta-[
Move backward one paragraph.
Meta-Delete
Delete previous word.
Meta-Shift Delete
Kill previous word.
Meta-Backspace
Delete previous word.
Meta-Shift Backspace
Kill previous word.
In addition, the pointer may be used to cut and paste text:
Button 1 Down
Start selection.
Button 1 Motion
Adjust selection.
End selection (cut).
Button 2 Down
Insert current selection (paste).
Button 3 Down
Extend current selection.
Button 3 Motion
Adjust selection.
Button 3 Up
End selection (cut).
Confirmation Dialog Boxes
Whenever you press a button that may cause you to lose some work or is otherwise dangerous, a popup dialog box will appear asking you to confirm the action. This window will contain an Abort or No button and a Confirm or Yes button. Pressing the No button cancels the operation, and pressing Yes will proceed with the operation.
Some dialog boxes contain messages from mh. Clicking on the message field will cause the dialog box to resize so that you can read the entire message.
Message Sequences
An mh message sequence is just a set of messages associated with some name. They are local to a particular folder; two different folders can have sequences with the same name. In all folders, the sequence “all” is predefined; it consists of the set of all messages in that folder. As many as nine sequences may be defined for each folder, including the predefined “all” sequence. (The sequence “cur” is also usually defined for every folder; it consists of only the current message. xmh hides “cur” from the user, instead placing a “+” by the current message. Also, xmh does not support the “unseen” sequence, so that one is also hidden from the user.)
The message sequences for a folder (including one for “all”) are displayed in the Sequence menu, below the sequence commands. The table of contents (also known as the “toc”) is at any one time displaying one message sequence. This is called the “viewed sequence,” and its name will be displayed in the toc title bar just after the folder name. Also, at any time one of the sequences in the menu will have a check mark next to it. This is called the “selected sequence.” Note that the viewed sequence and the selected sequence are not necessarily the same. (This all pretty much corresponds to the way the folders work.)
The Open Sequence, Add to Sequence, Remove from Sequence, and Delete Sequence commands are active only if the viewed folder contains message-sequences.
Note that none of the above actually affect whether a message is in the folder. Remember that a sequence is a set of messages within the folder; the above operations just affect what messages are in that set.
To create a new sequence, select the Pick menu entry. A new window will appear, with lots of places to enter text. Basically, you can describe the sequence's initial set of messages based on characteristics of the message. Thus, you can define a sequence to be all the messages that were from a particular person, or with a particular subject, and so on. You can also connect things up with boolean operators, so you can select all things from “weissman” with the subject “xmh”
Hopefully, the layout is fairly obvious. The simplest cases are the easiest: just point to the proper field and type. If you enter in more than one field, it will only select messages which match all non-empty fields.
The more complicated cases arise when you want things that match one field or another one, but not necessarily both. That's what all the or buttons are for. If you want all things with the subject “xmh” or “xterm,” just press the or button next to the Subject: field. Another box will appear where you can enter another subject.
If you want all things either from “weissman” or with subject “xmh,” but not necessarily both, select the -Or- button. This will essentially double the size of the form. You can then enter weissman in a from: box on the top half, and “xmh” in a subject: box on the lower part.
If you select the Skip button, then only those messages that don't match the fields on that row are included.
Finally, several more boxes will appear in the bottom part of the window. One is the name of the sequence you're defining. (It defaults to the name of the selected sequence when Pick was pressed, or to “temp” if “all” was the selected sequence.) Another box defines which sequence to look through for potential members of this sequence; it defaults to the viewed sequence when Pick was pressed.
Two more boxes define a date range; only messages within that date range will be considered. These dates must be entered in 822-style format: each date is of the form dd mmm yy hh:mm:ss zzz, where dd is a one or two digit day of the month, mmm is the three-letter abbreviation for a month, and yy is a year. The remaining fields are optional: hh, mm, and ss specify a time of day, and zzz selects a time zone. Note that if the time is left out, it defaults to midnight; thus if you select a range of “7 nov 86” - “8 nov 86”, you will get only messages from the 7th, as all messages on the 8th will have arrived after midnight.
Date field specifies which date field in the header to look at for this date range; it probably won't be useful to anyone. If the sequence you're defining already exists, you can optionally merge the old set with the new; that's what the Yes and No buttons are all about. Finally, you can OK the whole thing, or Cancel it.
In general, most people will rarely use these features. However, it's nice to occasionally use Pick to find some messages, look through them, and then hit Delete Sequence to put things back in their original state.
Widget Hierarchy
In order to specify resources, it is useful to know the hierarchy of widgets which compose xmh. In the notation below, indentation indicates hierarchical structure. The widget class name is given first, followed by the widget instance name. The application class name is Xmh.
The hierarchy of the main toc and view window is identical for additional toc and view windows, except that a topLevelShell widget is inserted in the hierarchy between the application shell and the Paned widget.
Xmh xmh Paned xmh SimpleMenu folderMenu SmeBSB open SmeBSB openInNew SmeBSB create SmeBSB delete SmeLine line SmeBSB close SimpleMenu tocMenu SmeBSB inc SmeBSB commit SmeBSB pack SmeBSB sort SmeBSB rescan SimpleMenu messageMenu SmeBSB compose SmeBSB next SmeBSB prev SmeBSB delete SmeBSB move SmeBSB copy SmeBSB unmark SmeBSB viewNew SmeBSB reply SmeBSB forward SmeBSB useAsComp SmeBSB print SimpleMenu sequenceMenu SmeBSB pick SmeBSB openSeq SmeBSB addToSeq SmeBSB removeFromSeq SmeBSB deleteSeq SmeLine line SmeBSB all SimpleMenu viewMenu SmeBSB reply SmeBSB forward SmeBSB useAsComp SmeBSB edit SmeBSB save SmeBSB print SimpleMenu optionMenu SmeBSB reverse Viewport.Core menuBox.clip Box menuBox MenuButton folderButton MenuButton tocButton MenuButton messageButton MenuButton sequenceButton MenuButton viewButton MenuButton optionButton Grip grip Label folderTitlebar Grip grip Viewport.Core folders.clip Box folders MenuButton inbox MenuButton drafts SimpleMenu menu SmeBSB <folder_name> ⋮ Grip grip Label tocTitlebar Grip grip Text toc Scrollbar vScrollbar Grip grip Label viewTitlebar Grip grip Text view Scrollbar vScrollbar Scrollbar hScrollbar
The hierarchy of the Create Folder popup dialog box:
transientShell prompt
Dialog dialog
Label label
Text value
Command okay
Command cancel
The hierarchy of the Notice dialog box, which reports messages from mh:
transientShell notice
Dialog dialog
Label label
Text value
Command confirm
The hierarchy of the Confirmation dialog box:
The hierarchy of the dialog box which reports errors:
transientShell error
Dialog dialog
Label label
Command OK
The hierarchy of the composition window:
topLevelShell xmh
Paned xmh
Label composeTitlebar
Text comp
Viewport.Core compButtons.clip
Box compButtons
Command close
Command send
Command reset
Command compose
Command save
Command insert
The hierarchy of the view window:
topLevelShell xmh
Paned xmh
Label viewTitlebar
Text view
Viewport.Core viewButtons.clip
Box viewButtons
Command close
Command reply
Command forward
Command useAsComp
Command edit
Command save
Command print
The hierarchy of the pick window:
(Unnamed widgets have no name.)
topLevelShell xmh
Paned xmh
Label pickTitlebar
Viewport.core pick.clip
Form form
Form
The first 6 rows of the pick window have identical structure:
Form
Toggle
Toggle
Label
Text
Command
Form
Toggle
Toggle
Text
Text
Command
Form
Command
Viewport.core pick.clip
Form form
Form
Form
Label
Text
Label
Text
Form
Label
Text
Label
Text
Label
Text
Form
Label
Toggle
Toggle
Form
Command
Command
See Appendix G, Athena Widget Resources for a list of resources that can be set for the Athena widgets.
Application-specific Resources
Resource instance names begin with a lowercase letter but are otherwise identical to the class name.
If TocGeometry, ViewGeometry, CompGeometry, or PickGeometry are not specified, then the value of Geometry is used instead. If the resulting height is not specified (e.g., “”, “=500”, “+0-0”), then the default height of windows is calculated from fonts and line counts. If the width is not specified (e.g., “”, “=x300”, “-0+0), then half of the display width is used. If unspecified, the height of a pick window defaults to half the height of the display.
Any of these options may also be specified on the command line by using the X Toolkit Intrinsics resource specification mechanism. Thus, to run xmh showing all message headers,
% xmh -xrm ‘*HideBoringHeaders:off’
The following resources are defined:
Banner
A short string that is the default label of the folder, Table of Contents, and view. The default is:
xmh MIT X Consortium R4
BlockEventsOnBusy
Whether to disallow user input and show a busy cursor while xmh is busy processing a command. Default is True.
BusyCursor
The name of the symbol used to represent the position of the pointer, displayed if BlockEventsOnBusy is True, when xmh is processing a time-consuming command. The default is watch.
BusyPointerColor
The foreground color of the busy cursor. Default is XtDefaultForeground.
CheckFrequency
How often to check for new mail, make checkpoints, and rescan the Table of Contents, in minutes. If CheckNewMail is True, xmh checks to see if you have new mail each interval. If MakeCheckpoints is True, checkpoints are made every fifth interval. Also every fifth interval, the Table of Contents is checked for inconsistencies with the file system, and rescanned. To prevent all of these checks from occurring, set CheckFrequency to 0. The default is 1.
CheckNewMail
If True, xmh will check at regular intervals to see if new mail has arrived for any of the folders. A visual indication will be given if new mail is waiting to be retrieved. Default is True. (See “Bugs.”) The interval can be adjusted with the Check-Frequency resource.
CommandButtonCount
The number of command buttons to create in a buttonbox in between the toc and the view areas of the main window. xmh will create these buttons with the names button1, button2 and so on, in a box with the name commandBox. The user can specify labels and actions for the buttons in a private resource file; see the section on “Actions.” The default is 0.
CompGeometry
Initial geometry for windows containing compositions.
The name of the symbol used to represent the pointer. Default is left_ptr.
DraftsFolder
The folder used for message drafts. Default is drafts.
Geometry
Default geometry to use. Default is none.
HideBoringHeaders
If “on”, then xmh will attempt to skip uninteresting header lines within messages by scrolling them off. Default is on.
InitialFolder
Which folder to display on startup. Can also be set with the command-line option -initial. Default is inbox.
InitialIncFile
The file name of your incoming mail drop. xmh tries to construct a filename for the inc -file command, but in some installations (e.g., those using the Post Office Protocol) no file is appropriate. In this case, InitialIncFile should be specified as the empty string, and inc will be invoked without a -file argument. The default is to use the value of the environment variable MAIL, or if that is not set, to append the value of the environment variable USER to /usr/spool/mail/.
MailPath
The full path prefix for locating your mail folders. May also be set with the command-line option, -path. The default is the Path component in $HOME/.mh_profile, or $HOME/Mail if none.
MailWaitingFlag
If True, xmh will attempt to set a indication in its icon when new mail is waiting to be retrieved. If this option is True, then CheckNewMail is assumed to be True as well. The -flag command line option is a quick way to turn MailWaitingFlag on.
MakeCheckpoints
If True, xmh will attempt to save checkpoints of volatile information. The frequency of checkpointing is controlled by the resource CheckFrequency.
MhPath
The directory in which to find the mh commands. If a command isn't found here, then the directories in the user's path are searched. Default is /usr/local/mh6.
PickGeometry
Initial geometry for pick windows.
PointerColor
The foreground color of the pointer. Default is XtDefaultForeground.
PrefixWmAndIconName
Whether to prefix the window and icon name with “xmh:”. Default is True.
The sh command to execute to print a message. Note that standard output and standard error must be specifically redirected! If a message or range of messages is selected for printing, the full file path of each message file is appended to the specified print command. The default is enscript >/dev/null 2>/dev/null.
ReplyInsertFilter
A shell command to be executed when the Insert button is activated in a composition window. The full path and filename of the source message is added to the end of the command before being passed to sh(1). The default filter is cat; i.e., it inserts the entire message into the composition. Interesting filters are: awk -e ‘{print “ “ $0}’ or <mh directory>/lib/mhl -form mhl.body.
ReverseReadOrder
When True, the next message will be the message prior to the current message in the Table of Contents, and the previous message will be the message after the current message in the Table of Contents. The default is False.
SendBreakWidth
When a message is sent from xmh, lines longer than this value will be split into multiple lines, each of which is no longer than SendWidth. This value may be overridden for a single message by inserting an additional line in the message header of the form SendBreakWidth: value. This line will be removed from the header before the message is sent. The default is 85.
SendWidth
When a message is sent from xmh, lines longer than SendBreakWidth characters will be split into multiple lines, each of which is no longer than this value. This value may be overridden for a single message by inserting an additional line in the message header of the form SendWidth: value. This line will be removed from the header before the message is sent. The default is 72.
SkipCopied
Whether to skip over messages marked for copying when using View Next Message and View Previous Message. Default is True.
SkipDeleted
Whether to skip over messages marked for deletion when using View Next Message and View Previous Message. Default is True.
SkipMoved
Whether to skip over messages marked for moving to other folders when using View Next Message and View Previous Message. Default is True.
StickyMenu
If True, when popup command menus are used, the most recently selected entry will be under the cursor when the menu pops up. Default is False. See the file clients/xmh/Xmh.sample for an example of how to specify resources for pop up command menus.
Directory for xmh to store temporary directories. For privacy, a user might want to change this to a private directory. Default is /tmp.
TocGeometry
Initial geometry for master xmh windows.
TocPercentage
The percentage of the main window that is used to display the Table of Contents. Default is 33.
TocWidth
How many characters to generate for each message in a folder's Table of Contents. Default is 100. Use 80 if you plan to use mhl a lot, because it will be faster, and the extra 20 characters may not be useful.
ViewGeometry
Initial geometry for windows showing only a view of a message.
Actions
Because xmh provides action procedures which correspond to command functionality and installs accelerators, users can customize accelerators in a private resource file. xmh provides action procedures which correspond to entries in the command menus; these are given in the sections describing menu commmands. For examples of specifying customized resources, see the file clients/xmh/Xmh.sample. Unpredictable results can occur if actions are bound to events or widgets for which they were not designed.
In addition to the actions corresponding to commands, these action routines are defined:
XmhPushFolder([foldername,…])
Pushes each of its argument(s) onto a stack of folder names. If no arguments are given, the selected folder is pushed onto the stack.
XmhPopFolder()
Pops one folder name from the stack and sets the selected folder.
XmhPopupFolderMenu()
Should always be taken when the user selects a folder button. A folder button represents a folder and zero or more subfolders. The menu of subfolders is built upon the first reference, by this routine. If there are no subfolders, this routine will mark the folder as having no subfolders, and no menu will be built. In that case, the menu button emulates a toggle button. When subfolders exist, the menu will popup, using the menu button action PopupMenu().
XmhSetCurrentFolder()
Allows menu buttons to emulate toggle buttons in the function of selecting a folder. This action is for Menubutton widgets only, and sets the selected folder.
XmhLeaveFolderButton()
Ensures that the menu button behaves properly when the user moves the pointer out of the menu button window.
XmhPushSequence([sequencename, …])
Pushes each of its arguments onto the stack of sequence names. If no arguments are given, the selected sequence is pushed onto the stack.
XmhPopSequence()
Pops one sequence name from the stack of sequence names, which then becomes the selected sequence.
XmhPromptOkayAction()
Equivalent to pressing the Okay button in the Create Folder popup.
XmhCancelPick()
Equivalent to pressing the Cancel button in the Pick window.
Customization Using mh
The initial text displayed in a composition window is generated by executing the corresponding mh command; i.e., comp, repl, or forw, and therefore message components may be customized as specified for those commands. comp is executed only once per invocation of xmh and the message template is re-used for each successive new composition.
Files
~/Mail ~/.mh_profile—mh profile. /usr/local/mh6—mh commands. ~/Mail/<folder>/.xmhcache—Scan folder. ~/Mail<folder>/.mh_sequences—Sequence definitions. /tmp—Temporary files.
See Also
X, xrdb, mh(1), enscript(1); Appendix G, Athena Widget Resources; Volume Four, X Toolkit Intrinsics Programming Manual; Volume Five, X Toolkit Intrinsics Reference Manual, and the Nutshell Handbook MH and xmh: Email for Users and Programmers.
Bugs
Printing support is minimal.
Should handle the “unseen” message sequence.
Should determine by itself if the user hasn't used mh before, and offer to create the .mh_profile, instead of hanging on inc.
Still a few commands missing (rename folder, remail message).
A bug in mh limits the number of characters in .mh_sequences to BUFSIZ. When the limit is reached, the .mh_sequences file often becomes corrupted, and sequence definitions may be lost.
Except for the icon, there isn't an indication that you have new mail.
There should be a resource, ShowOnInc, which when True, would show the current message in the view after incorporating new mail.
The CheckFrequency resource should be split into two separate resources.
WM_SAVE_YOURSELF protocol is ignored.
WM_DELETE_WINDOW protocol doesn't work right when requesting deletion of the first toc and view, while trying to keep other xmh windows around.
Doesn't support annotations when replying to messages.
Copyright
Copyright 1988, 1989, Digital Equipment Corporation.
Copyright 1989, Massachusetts Institute of Technology.
See X for a full statement of rights and permissions.
Author
Terry Weissman, Digital Western Research Laboratory;
Modified by Donna Converse, MIT X Consortium.