This chapter gives an overview of other clients available with X, including window and display information clients, printing utilities, the xkill program, and several “desk accessories.”
In This Chapter:
In addition to twm and xterm, the MIT distribution includes many other clients. As X becomes more widely available, there will doubtless be many applications available from third parties, just as there are in the PC world.
The clients discussed in this chapter are grouped according to basic functionality, as follows:
• Desk accessories: xclock, oclock, xcalc, xbiff, xload, and xman.
• Printing utilities: xwd, xpr, and xdpr.
• Program to remove a client window: xkill.
• Window and display information programs: xwininfo, xlswins, xlsclients, and xdpyinfo.
• Alternative window managers and other user-contributed clients.
In addition, we’ve included a brief discussion of X Toolkit applications.
Most sections in this chapter are intended to acquaint you with the major features of some of the available clients. Additional detailed information is provided on the reference pages for each client in Part Three of this guide.
The clients xclock, oclock, xcalc, xload, xbiff, and xman can be thought of as desk accessories. (Desk accessories is a term we’ve borrowed from the Macintosh environment, meaning small applications available—and useful—at any time.)
You can start these clients from the command line in any xterm window, or, if you like, you can add them to a twm menu (see Chapter 10, Customizing the twm Window Manager).
The standard release of X includes two clients that display the time: xclock and oclock. The oclock client has been added to the standard distribution of X in Release 4.
xclock continuously displays the time, either in analog or digital form, in a standard window. The analog xclock shows a round 12-hour clock face, with tick marks representing the minutes. The digital xclock shows the 24-hour time (14:30 would be 2:30 PM) as well as the day, month, and year. You can run more than one clock at a time. The analog dock is the default. Figure 7-1 shows two xclock applications being run (an analog clock above a digital clock).
Usually when you invoke xclock you will leave the clock running. However, if you experiment with xclock to test size, location, or color, you will notice that there is no obvious way to delete an unwanted clock. (Moving the cursor to the clock and pressing Control-C, Control-D, q, or Q doesn’t work with xclock.) Actually, if you are running Release 2 or 3 of X, the only way to kill the xclock process is as follows. First, display the current X processes with the command:
% ps -aux | grep xclock
For System V, use the command:
% ps -e | grep xclock
and then kill the process number for the clock as described in Chapter 2, Getting Started.
If you are running Release 4 of X, and thus are using the twm window manager. you can remove an xclock by using the
Delete command of the
Twm menu. (See Chapter 3, Using the twm Window Manager, for more details.)
The oclock client (available as of Release 4) displays the time in analog form, on a round 12-hour clock face without tick marks. The only features of an oclock display are the round clock outline, hour and minute hands, and the “jewel” marking 12 o’clock.
Though it is somewhat more difficult to read the precise time on the simple oclock display, the oclock is perhaps a little more aesthetic than the analog xclock. If you try to resize the oclock, you’ll discover that it’s possible to “stretch” it into various oblong shapes.
Though the default colors for oclock are black and white, it was designed to be run in color. The minute hand, hour hand, jewel, clock border, and background can all be set to a color, using either command line options (as described in Chapter 8, Command Line Options) or by specifying client resources (as described in Chapter 9, Setting Resources.) See the oclock reference page in Part Three of this guide for the necessary command line options and color suggestions.
As is the case with xclock, there is no simple way to remove an oclock window. Use the UNIX commands ps, grep, and kill in the sequence described above.
The time displayed by both xclock and oclock is the system time set and displayed with the UNIX date(1) command.
xcalc is a scientific calculator that can emulate a TI-30 or an HP-10C. Once you place the pointer within the xcalc window, the calculator can be operated in two ways: with the pointer, by clicking the first pointer button on the buttons in the calculator window, or with the keyboard, by typing the same numbers and symbols that are displayed in the calculator window. When using the first method, notice that the pointer appears as a small hand, enabling you to “press” the buttons. Figure 7-4 shows xcalc on the screen.
This is the version of the calculator provided with Release 4 of X. As you can see, it features oval buttons. If you are running an earlier release, the calculator will have rectangular buttons and may also have darker background coloring. These differences do not affect functionality. However, the Release 3 and Release 4 versions of xcalc do work somewhat differently. We’ve described some of those differences below. For additional information, see the xcalc reference page in Part Three of this guide.
The long horizontal window along the top of the calculator is the display in which the values are punched on the calculator and their results are displayed. You can enter values either by clicking on the calculator keys with the pointer, or by pressing equivalent keys on the keyboard. Most of the calculator keys have keyboard equivalents. The non-obvious equivalents are described on the xcalc reference page in Part Three.
% xcalc &
You can also operate the calculator in Reverse Polish Notation (like a Hewlett-Packard HP-10C calculator), by typing:
% xcalc -rpn &
In Reverse Polish Notation the operands are entered first, then the operator. For example,
5 * 4 = would be entered as
5 Enter 4 *. This entry sequence is designed to minimize keystrokes for complex calculations.
As of Release 4, xcalc allows you to select the number in the calculator display using the first (left) pointer button and paste it in another window using the second (middle) button. See Chapter 4, The xterm Terminal Emulator, for information about copying and pasting text selections.
The Release 4 xcalc can also be resized. In prior releases, this was not possible.
Also as of Release 4, xcalc no longer emulates a slide rule.*
For more information on the function of each of the calculator keys, see the xcalc reference page in Part Three of this guide.
Terminate the calculator by either:
• Clicking the third pointer button (usually the rightmost button) on the TI calculator’s AC key or the HP calculator’s ON key, or:
• Positioning the pointer on the calculator and typing q, Q, or Control-C.
xbiff is a simple program that notifies you when you have mail. It puts up a window showing a picture of a mailbox. When you receive new mail, a beep is emitted from the keyboard, the flag on the mailbox goes up, and the image changes to reverse video. Figure 7-5 shows the xbiff mailbox before and after mail is received.
After you read your mail, the image changes back to its original state. Or you can click on the full mailbox icon with any pointer button to change it back to empty. (Regardless of the number of mail messages when you do this, xbiff remembers the current size of your mail file to be the empty size.)
xload periodically polls the system for the load average, and graphically displays that load using a simple histogram. By default, xload polls the system every 5 seconds. You can change this frequency with the
-update option. For example, if you type the following command at an xterm window:
% xload -update 3 &
you can interactively place an xload window polling every 3 seconds.
If you are using both the local machine and remote machines, you can display loads for all systems and do your processing on the system that is fastest at the time.
The xman client allows you to display and browse through formatted versions of manual pages (reference pages). By default, xman lets you look at the standard UNIX manpages found in subdirectories of the directory /usr/man. The standard version of X assumes there are ten subdirectories: man1 through man8, corresponding to the eight sections of manpages in the UNIX documentation set; manl (man local) and mann (man new). You can specify other directories by setting the MANPATH system variable. (The individual directory names should be separated by colons.)
This section describes the version of xman provided with Release 4 of X. From a user’s viewpoint, the general operation of the client has not changed much since prior releases, but the organization of menus and options has changed. If you are running Release 3 of X, read this section for an idea of how the client works and then take a look at the next section, “Release 3 xman,” for a summary of the differences.
Regardless of the version of X, you run xman by typing:
% xman &
in an xterm window.
The initial xman window, shown in Figure 7-7, is a small window containing only a few commands.
This window is small enough to be displayed for prolonged periods during which you might have need to examine UNIX manual pages. You select a command by clicking on it with the first pointer button.
Manual Page command brings up a larger window in which you can display a formatted version of any manual page in the MANPATH. By default, the first page displayed contains general help information about xman. Use this information to acquaint yourself with the client’s features. (The actual xman reference page in Part Three of this guide primarily describes how to customize the client.)
Once you’ve opened this larger window, you can display formatted manual pages in it.* Notice the horizontal bar spanning the top edge of the window. (If you’re running twm or a similar window manager, this bar appears beneath the titlebar provided by the window manager.) The bar is divided into three parts, labeled
Options, Sections, and
Xman Help. The part currently labeled
Xman Help is merely informational and the text displayed in it will change depending on the contents of the window. The parts labeled
Sections are actually handles to two xman menus.
If you place the pointer on the
Options box and press and hold down the first button, a menu called
Xman Options will be displayed below. The menu is pictured in Figure 7-8.
The functionality of these options is described in the on-line xman help page. To select an option, move the pointer down the menu and release the first button on the option you want. The option you will probably want to use most frequently is the first one,
Display Directory lists the manpages in the current manpage directory (also called a “section”). By default, this is man1, the user commands. When you list the contents of man1 in this way, the informational section of the horizontal bar reads
Directory of: (1) User Commands. You can then display a formatted version of any command reference page in the list by clicking on the command’s name with the first pointer button. Figure 7-9 shows the formatted reference page for the UNIX cd(1) command.
To display another manual page from the same directory, display the
Xman Options menu again. Select
Display Directory, and the directory listing is again displayed in the window. Then click on another command name to display its manual page in the window. (If you decide not to display another manpage, you can remove the directory listing and go back to the manpage previously displayed by using the second
Xman Options menu selection,
Display Manual Page.
Display Directory and
Display Manual Page are toggles of one another.)
To display a manual page from another directory in the MANPATH, you must first change to that directory using the second xman menu,
Xman Sections. You bring up the menu by placing the pointer in the
Sections box in the application’s titlebar and holding down the first button. The
Xman Sections menu lists the default directories of UNIX manual pages, as in Figure 7-10.
You can select another directory of manpages from which to choose with the first pointer button. Once you select a directory, the files in that directory are listed in the window. Again, you display a page by clicking on its name with the first pointer button.
You can display more than one “browsing” window simultaneously by selecting the
Open New Manpage option from the
Xman Options menu. An additional manpage window will be opened, again starting with the help information.
You can remove a browsing window by selecting the
Remove This Manpage option from the
Xman Options menu. (Prior to Release 4, selecting this option resulted in an error and caused the xman program to exit.)
Quit from the
Xman Options menu or from the initial xman window causes the client to exit.
In the Release 3 version of xman, the horizontal bar spanning the top of the browsing window merely contains information about the contents of the window. It is not divided and it does not contain obvious text handles to any menus.
Though it may not be readily apparent, you can access the
Xman Options menu simply by placing the pointer in the horizontal bar. You can then display manpages from the default directory by following the steps outlined in the previous section.
Xman Options is the only menu directly accessible from the horizontal bar.
The Release 3
Xman Options menu differs slightly in options and organization from the Release 4 menu. The Release 3 menu is pictured in Figure 7-11.
Again, you can acquaint yourself with the various options by reading the help information displayed on the initial manual page. Most of the options and functionality are the same as described above for Release 4.
The most significant difference is the method of changing directories within the MANPATH. As we’ve seen in the Release 4 version of xman, this is accomplished through the
Xman Sections menu, which is accessible directly from the horizontal bar. In the Release 3 version, in order to change directories you must first bring up the
Xman Options menu. Then select the first option,
Change Section (which has been removed from the Release 4 menu). A sub-menu of
Xman Options, called
Manual Sections, will be displayed. This sub-menu is the R3 equivalent of the R4
Xman Sections menu.
Xman Sections, the
Manual Sections menu lists the default directories of UNIX manual pages. You can select an alternate directory by the method described in the previous section.
The Release 3 version of xman has one serious limitation. Selecting the option
Remove This Manpage from the
Xman Options menu results in an error and causes the xman program to exit (This error has been corrected in Release 4.)
xwd stores window images in a formatted window dump file. This file can be read by various other X utilities for redisplay, printing, editing, formatting, archiving, image processing, etc.
To create a window dump file, type:
% xwd > file
The pointer will change to a small crosshair. Move the crosshair pointer to the desired window and click any button. The keyboard bell rings once when the dump starts and twice in rapid succession when the dump is finished.
To make a dump of the entire root window (and all windows on it), use the
-root option, as in the following:
% xwd -root > file
When you select a single window, by default xwd takes an image of the window proper. As of Release 4, to include a window manager frame or titlebar, use the
To redisplay a file created with xwd in a window on the screen, use the xwud client, an undumping utility. Specify the dump file to display as an argument to the
-in option, as in the following:
% xwud -in file
Then remove the image be typing Control-C in the xterm from which you started xwud.
xpr takes as input an X Window System dump file produced by xwd and converts it to a printer-specific format that can be printed on the DEC LN03 or LA100 printer, a PostScript printer such as the Apple LaserWriter, the IBM PP3812 page printer, and as of Release 4, the HP LaserJet (or other PCL printers) or the HP PaintJet. By default, output is formatted for the DEC LN03 printer. Use the
-device option to format for another printer. For example, to format a window dump file for a PostScript printer, type:
% xpr -device ps file > file.ps
Other options allow you to change the size, add headers or footers, and so on. See the xpr reference page in Part Three of this guide for details.
You can use xwd and xpr together, using the standard UNIX pipe mechanism. For example:
% xwd | xpr -device ps | lpr
The xdpr command rolls these three separate commands into one. See the xdpr reference page in Part Three of this guide for details.
Note that when you start piping together the output of X clients, you run into some ambiguities. For example, if you pipe the output of xwd to xpr, and for some reason, the xpr command fails, xwd will still be there waiting for pointer input. The original UNIX pipe mechanism doesn’t have the concept of data dependent on pointer input! The integration of the UNIX model of computing (in which standard input and output are always recognized), and the window model, is not always complete, leading sometimes to unexpected behavior.
As an even more flagrant example, you can create a pipe between two programs the first of which doesn’t produce standard output, and the second of which doesn’t recognize standard input. The shell doesn’t know any better, and the programs themselves go on their merry way with pointer and windows.
However, it is nice to know that you can pipe together output of programs, even when some of those programs may not produce output until you intervene with the pointer.
Even without pipes, you should start thinking about how these programs could work together. For example, the pictures of fonts in Appendix E, Release 3 and 4 Standard Fonts, were created by these steps:
1. Display a font with xfd. (See Chapter 5, Font Specification, for instructions on how to use xfd.)
2. Resize the window to improve readability, using the twm resize box on the titlebar.
3. Create a window dump file with the command
xwd > file.
4. Create a PostScript file from the dump with the command:
xpr -device ps file > file.ps
5. Print the PostScript file on an Apple LaserWriter with the standard print command lpr(1).
Even though the UNIX shell will accept a pipe between xfd, xwd, and xpr, what actually happens is that xwd starts up faster than xfd, and is ready to dump a window before the xfd window appears.
The xkill program allows you to kill a client window, or more specifically, to force the server to end the connection to the client. The process exits and the associated window is removed.
xkill is a fairly drastic method of terminating a client and should not be used as the method of preference. In most cases, clients can be terminated in other ways. The possible repercussions of using xkill and some of the alternatives are discussed in the next section.
xkil1 is intended primarily to be used in cases where more conventional methods of removing a client window do not work. It is especially useful when programs have displayed undesired windows on the screen. To remove a stubborn client window, type:
on the command line of an xterm window. The pointer changes to a “draped box” pointer and you are instructed to:
Select the window whose client you wish to kill with button 1 . . .
Move the draped box pointer to the window you want to remove, as in Figure 7-12, and click the first pointer button. The window is removed. (xkill does not allow you to select the root window.)
You can also specify the window to be killed by its resource ID. Every window has an identification number associated with it. The xwininfo client can be used to display a window’s resource ID (see the section “Window and Display Information” later in this chapter).
To remove a window using its ID number, type:
% xkill -id number
The window with the ID
number is removed. Killing a window by its ID number is more cumbersome, but it’s somewhat safer than choosing the window to be killed with the pointer. It’s too easy to click in the wrong place. (Of course, it’s less treacherous to use the pointer on an isolated window than a window in a stack.)
The most obvious problem with xkill is that it’s possible to kill the wrong window inadvertently. Perhaps less obvious is a problem inherent in ’killing’ a program. As a general rule, a command that ’kills’ a program does not give the program time to save or complete processes that are still running—in effect, to clean up after itself. The processes that can be adversely affected may be visible to the user, like an editing session, or they may be underlying system processes, like writing to or reading from a socket.
Most clients can be terminated in ways that allow them to finish all relevant processes and then exit cleanly. These methods should be attempted before you use xkill, or some other program that kills the client.
For example, you can generally remove an xterm window by typing in the window the same command you use to log off the system. You should also be able to remove an xterm window with various
Main Options menu commands, depending on the signals that can be interpreted by your system. (Some of these signals, such as SIGHUP and SIGTERM, are more gentle to the system. See the xterm reference page in Part Three of this guide for a list of menu commands and the signals they send.) An xcalc window can generally be removed by typing q, Q, or Control-C in the window. A bitmap window has a
Quit button box, etc. If you are running Release 4 of X, the
Twm menu also provides an item,
Delete, which allows you to safely remove a client window if the client has been written to comply with standard interclient communication conventions. (See Chapter 3, Using the twm Window Manager, for details.)
A few clients, such as oclock, cannot be removed except by killing. You must use xkill, or a similar method, to remove an oclock window.
Generally, however, you should exhaust the safer alternatives before you use xkill and other commands that kill a client.
When you want to remove a window, depending on the client and what commands it recognizes, try the following methods (roughly) in this order:
1. Methods that cause the client to exit after finishing relevant processes:
a. Special commands (e.g.,
logout, exit) or key sequences (e.g., Control-D. Control-C, q, Q) recommended to stop a client.
b. Certain application-specific menu items (e.g., for xterm, the
Main Options menu commands
Signal, Send TERM Signal, and
Quit; the bitmap
Delete item on the
Twm menu. (Whether this works depends on whether the client to be removed has been written to comply with the interclient communication conventions. If other safe methods have failed and
Delete doesn’t work, you may need to take more drastic measures.)
2. When these methods don’t work, or don’t apply (as in the case of oclock), then use commands or menu items that kill the client:
Send KILL Signal item on the xterm
Main Options menu, for removing xterm windows only (see Chapter 4, The xterm Terminal Emulator).
Kill item on the
Twm menu (see Chapter 3, Using the twm Window Manager). (If you are running Release 3 of X, you can use the
KiiiWindow item on the uwm
WindowOps menu. See Appendix B, The uwm Window Manager, for details.)
d. The xkill client.
Be warned that older versions of xkill can have surprising complications. For example, some older versions of xkill do not seem to work properly with the window manager twm. twm automatically becomes the parent process of all the top level windows in the window hierarchy. (See the discussion of xlswins later in this chapter for more information about the window hierarchy.) If you use xkill to kill a top level window, twm is killed instead, and the window remains. Most problems such as these should have been solved as of Release 3.
The standard release of X includes four clients that provide information about windows on the display and about the display itself. Much of the information is probably more relevant to a programmer than to the typical user. However, these clients also provide certain pieces of information, such as window geometry, window ID numbers, and the number and nature of screens on the display, that can assist you in using other clients.
The xwininfo client displays information about a particular window. As described in Chapter 8, Command Line Options, much of this information is useful in determining or setting window geometry. xwininfo also provides you with the window ID (also called the resource ID). Each window has a unique identification number associated with it. This number can be used as a command line argument with several clients. Most notably, the window ID can be supplied to the xkill client to specify the window be killed.†
To display information about a window, type the following command in an xterm window:
xwininfo ==> Please select the window about which you
==> would like information by clicking the
==> mouse in that window.
You can select any window on the display, including the window in which you’ve typed the command and the root window. (Rather than using the pointer, you can specify a window on the command line by supplying its title, or name, if it has no title, as an argument to xwininfo’s own
-name option. See Chapter 8, Command Line Options. for information about setting a client’s title and name. See the xwininfo reference page in Part Three of this guide for a list of its options.)
Figure 7-13 shows the statistics the Release 4 version of xwininfo supplies, with some typical readings.
These readings are for a login xterm window displayed using a 12 point Roman Courier font. All numerical information is in pixels, except depth, which is in bits per pixel. The twm window manager is also running. The statistics that are most significant for the average user are listed below:
xwininfo ==> Window id: 0x40000f (xterm)
==> Absolute upper-left X: 0
==> Absolute upper-left Y: 0
==> Relative upper-left X: 0
==> Relative upper-left Y: 21
==> Width: 578
==> Height: 316
==> Depth: 1
==> Border width: 1
==> Colormap: 0x80065
==> Corners: +0+0 -572+0 -572-582 +0-582
The first piece of information is the window ID. which can be used as an argument to xkill. Specifying the window to be killed by its ID number is somewhat less risky than choosing it with the pointer.
The other statistics (with the exception of depth) can be used to gauge the window’s geometry (size and position). The absolute upper-left X and Y correspond to the positive x and y offsets of the window from the root window. These figures can be used on the command line to specify window placement, as described in Chapter 8, Command Line Options.
The relative upper-left X and Y are significant only if you’re running a window manager, such as twm, that provides some sort of frame. The relative upper-left X and Y are the window’s x and y offsets relative to its frame. In this example, the relative upper-left Y of 21 pixels refers to the height of the window’s titlebar.
The four corners are listed with the upper left corner first and the other three clockwise around the window (i.e., upper right, lower right, lower left). The upper left corner always gives the positive x and y offsets for the window. The width and height in pixels are somewhat less useful, since the geometry option to xterm requires that these figures be specified in characters and lines. See Chapter 8, Command Line Options, for more information about window geometry and how to set it based on the results of xwininfo.
The values for window depth and colormap relate to how color is specified. See the discussion of color in Chapter 8 for more information.
Be aware that the Release 3 version of xwininfo does not provide relative x and y offsets. It does provide absolute x and y offsets, though they are labeled simply as:
==> Upper left X: 0
==> Upper left Y: 0
The other statistics provided by xwininfo are listed below:
==> Window class: InputOutput
==> Window Bit Gravity State: NorthWestGravity
==> Window Window Gravity State: NorthWestGravity
==> Window Backing Store State: NotUseful
==> Window Save Under State: no
==> Window Map State: IsViewable
==> Window Override Redirect State: no
These statistics have to do with the underlying mechanics of how a window is resized, moved, obscured, unobscured, and otherwise manipulated. They are inherent in the client program and you cannot specify alternatives. For more information on these and other window attributes, see Chapter 4 in Volume One, Xlib Programming Manual.
You can also use xwininfo with various options to display other window attributes. See the reference page in Part Three of this guide for details.
Windows are arranged in a hierarchy, much like a family tree, with the root window at the top. The xlswins client displays the window tree starting with the root window, listing each window by its resource ID and title (or name), if it has one. (See Chapter 8, Command Line Options, for a discussion of setting a client’s title and name with command line options.)
A resource ID can be supplied to xkill to specify the window to kill. You can also supply a resource ID to xwininfo to specify the window you want information about, or to xprop to get the window’s properties. Being able to display the ID numbers of all windows on the screen at once is especially helpful if one or more windows is obscured in the stack. The xwininfo client is virtually useless in situations in which one window is hidden behind another. xlswins allows you to determine, by process of elimination, which window is hidden—without having to circulate all the windows on your screen. You can then use xwininfo with the ID number (displayed by xlswins) to get information about the obscured window.
Figure 7-14 shows the results of xlswins for a simple window arrangement: a single xterm (login) window on a root window.
The xterm window is easily identified. Any client that displays a window, such as xterm, xclock, xfd, bitmap, etc., will be listed by name (in parentheses) following the ID number.* The root window is listed above the xterm in the window hierarchy. Client (and other) windows displayed on the root window are called children of the root window, in keeping with the family tree analogy. Thus, the root window is the parent of the xterm window. In the xlswins listing, a child window is indented once under its parent.
But what are the other windows listed in Figure 7-14? A superficial examination of these other windows provides a brief introduction to the inner workings of X. An underlying feature of X is that menus, boxes, icons, and even features of client windows, such as scrollbars, are actually windows in their own right. What’s more, these windows (and client window icons) may still be considered to exist, even when they are not displayed.
The two remaining windows are unnamed. From the relative indents of the windows, we can tell certain information. The first unnamed window is a child of the xterm, the second is a child of the child.
If we again run xlswins, this time requesting a long listing (with the
-l option), we get geometry information that helps identify each window, as shown in Figure 7-15.
The first number on each line refers to the level of the window in the hierarchy, the root window being at level 0, client windows at 1, etc. The first geometry string is the complete specification relative to the parent window. The second geometry string is the current position relative to the root window. A window at coordinates 0,0 would have the position +0+0 relative to the root. The two unnamed windows under xterm are the VT102 window and the window’s scrollbar, respectively. (The first xterm listing is the application shell window, which can be displayed both as a VT102 and a Tektronix window.)
The listing in Figure 7-15 was generated when the twm window manager was not running. Many of the features provided by twm, such as the window “frame” and its command buttons, the icon manager, and menus, are actually all windows. This greatly complicates the window hierarchy. If you run xlswins while twm is running, you can assume that most of the mysterious windows in the hierarchy are features provided by the window manager.
For more information on the window hierarchy, see Volume One, Xlib Programming Manual.
You can get a listing of the client applications running on a particular display by using xlsclients. Without any options, xlsclients displays a two-column list, similar to the following:
colorful xterm -geometry 80x24+10+10 -ls
colorful xclock -geometry -0-0
The first column shows the name of the display (machine) and the second the client running on it. The client is represented by the command line used to initiate the process.
This sample listing indicates that there is one xterm window and one xclock window running on the display
colorful. (The option
-ls following the xterm command reveals that the shell running in this window is a login shell.) The list is alphabetical.
You can use xlsclients to create an .xsession file, which specifies the clients you want to be run automatically when you log in. In order to do this, you must have set up client windows in an arrangement you like using command line options alone (that is, without having moved or resized windows via the window manager). You can then run xlsclients to print a summary of the command lines you used to set up the display and include those command lines in your .xsession file. See Appendix A, System Management, for information on setting up a user session.
By default, xlsclients lists the clients running on the display corresponding to the DISPLAY environment variable, almost always the local display. You can list the clients running on another display by using the
-display command line option. See Chapter 8, Command Line Options, for details.
With the option
-l (indicating long), xlsclients generates a more detailed listing. Figure 7-16 shows the long version of the listing above.
For each client, xlsclients displays six items of information: the window ID number, machine name, client name, icon name, command line used to run the client, and what are known as the instance and class resource names associated with the client.
As we’ll see in Chapter 8, Command Line Options, many clients, including xtenn, allow you to specify an alternate name for a client and a title for the client’s window. If you’ve specified a title, it will appear in the xlsclients
Name field. If you haven’t specified a title, but have specified a name for the application, the name will appear in this field. Neither of the clients in the sample display has been given an alternate name or title.
You use the instance and class resource names to specify default window characteristics, generally by placing them in a file in your home directory. This is described in detail in Chapter 9, Setting Resources.
The xdpyinfo client gives information about the X display, including the name of the display (contents of the DISPLAY variable), version and release of X, number of screens, current screen, and statistics relating to the color, resolution, input, and storage capabilities of each screen. The xdpyinfo reference page in Part Three of this guide shows a listing for a display that supports both a color and monochrome screen.
Much of the information provided by xdpyinfo has to do with how clients communicate information to one another and is more relevant to a programmer than to the typical user. However, the basic statistics about the name of the display, the version and release of X, and the number and nature of screens might be very helpful to a user, particularly one who is using a display for the first time.
In addition, the detailed information about each screen’s color capabilities can also be very valuable in learning how to use color more effectively. This information includes the default number of colormap cells: the number of colors you can use on the display at any one time. See Chapter 8, Command Line Options, for more information on the use of color and how to specify colors for many clients.
See Volume One, Xlib Programming Manual, for insights into some of the other information provided by xdpyinfo.
In addition to the clients in the standard MIT X distribution, there are many user-contributed clients available in the X source tree, distributed over Usenet, and perhaps included with various commercial distributions. If you have access to Usenet, the newsgroup comp.windows.x contains voluminous discussions of X programming and the newsgroup comp.sources.x contains sources.
Prior to Release 4, uwm (the universal window manager) was the official window manager shipped with the standard X Window System. As of Release 4, uwm is no longer supported, but is still available as a user-contributed client. However, be aware that uwm does not comply with accepted interclient communication conventions and thus, should probably not be the window manager of choice.
Several other window managers are widely used and have been tailored to reflect the interclient communication conventions proposed in Release 3. Some of the more popular window managers that reflect these conventions are:
|awm||Ardent window manager (written by Jordan Hubbard of Ardent Computer Corporation).|
|rtl||Tiled window manager (written by Ellis Cohen at Siemens Research & Technology Laboratories, RTL).|
|olwm||OPEN LOOK window manager (developed by AT&T).|
|mwm||Motif window manager (written by Ellis Cohen at the Open Software Foundation).|
Appendix C, The OSF/Motif Window Manager, discusses mwm in greater detail.
Commercial products (such as spreadsheets, word processors, and graphics or publishing applications) based on the X Window System are also becoming available.
Many clients have been written (or rewritten) with a programming library called the X Toolkit. The X Toolkit provides a number of predefined components called widgets. Widgets make it easier to create complex applications; they also ensure a consistent user interface between applications.
Most of the clients described in this guide were written before the X Toolkit was fully developed. Although they have since been rewritten to use the X Toolkit, they don’t necessarily make full use of all its features.
However, most of the standard clients use enough of these features that you can see what to expect from future applications that are based more fully on the X Toolkit.
This section briefly reviews some features of X Toolkit applications, with reference to where they are implemented in the current crop of clients. For a comprehensive treatment of the X Toolkit, see Volumes Four and Five. X Toolkit Intrinsics Programming Manual and X Toolkit Intrinsics Reference Manual.
A dialog box is used when an application requires a small piece of information from the user, such as a filename. A dialog box typically has three elements: it always has the first element, and may or may not have the second and/or third elements in the following list:
• A prompt that identifies the purpose of the widget This might be as simple as the string “Filename:”.
• An area in which you can type your response.
• Command buttons that allow you to confirm or cancel the dialog input.
A dialog box is usually a pop-up window, which goes away after the required information is provided.
The X client bitmap is one of the few current applications that use a dialog box. It displays the dialog displayed in Figure 7-17 when you quit the application. Future X applications can be expected to make far more extensive use of dialogs like this.
Each command button in the box is itself a widget. A command button is a rectangle that contains a text label. When the pointer is on the button, its border is highlighted to indicate that the button is available for selection. When a pointer button is clicked, some action (presumably indicated by the label) is performed by the program.
Some applications use the following convention for command buttons. Whenever you press a button that may cause you to lose some work or is otherwise dangerous, a second dialog box will appear asking you to confirm the action. This dialog box will contain an
Abort button and a
Confirm button. Pressing the
Abort button cancels the operation, and pressing the
Confirm button will proceed with the operation.
(A very handy shortcut exists in some applications: if you press the original button again, it will be interpreted as a
Confirm. If you press any other command button, it will be interpreted as an
As described in the discussion of xterm in Chapter 4, The xterm Terminal Emulator, applications can use a scrollbar to move up and down through data that is too large to fit in a window. A scrollbar is an X Toolkit widget.
The scrollbar consists of a sliding bar (often called the thumb) within a columnar slide region. The size of the thumb within the scrollbar corresponds to the amount of the data displayed within the visible portion of the window with respect to the entire body of data. If no data has yet been displayed in the window, the thumb fills the entire scrolling region, as shown in Figure 7-18.
xterm uses a vertical scrollbar; other applications may use a horizontal scrollbar, or both. One type of widget that can have both horizontal and vertical scrollbars is called a viewport.
When the pointer is moved into the scrollbar, the cursor appears as an arrow that points in the direction that scrolling can occur. If scrolling can occur in either direction, the cursor appears as a two-headed arrow.
When the middle pointer button is clicked at any point in the scrollbar, the thumb moves to that point, and the data in the window scrolls to the corresponding position. When the middle pointer button is pressed and held down, the thumb can be “dragged” to a desired position in the scrollbar. If you click the first (left) button in the scrollbar, the data in the window scrolls up, toward the end of the information in the window. If you click the third (right) button, the data in the window scrolls down, towards the beginning of the information in the window.
As described in the discussion of xterm in Chapter 4, when you select contents from one file, those contents become the PRIMARY selection, which is available to other clients. For example, you can select text in one xterm window and paste the text into any other xterm window. See Chapter 4, The xterm Terminal Emulator, for a complete discussion of copying and pasting. In applications written with the X Toolkit, selections are a method of widget-to-widget communication.
A VPaned widget arranges a series of windows one above the other without overlapping (i.e., they are vertically tiled).
A small region, called a grip, appears on the border between each subwindow. When the pointer is positioned on the grip and a button pressed, an arrow is displayed that indicates the direction in which the border between the two windows can be moved. If you move the pointer in the direction of the arrow (while keeping the button depressed), one subwindow will grow, while the other will shrink.
The individual panes can be any other type of widget. For example, the xmh mail handler includes dialog boxes with buttons, viewports containing text widgets and so on, as shown in Figure 7-19. (We refer to the xmh client solely to illustrate vertical panes that can be used by other X clients. The current xmh client is not discussed in this guide.)
A viewport is a composite widget that provides a main window and horizontal and/or vertical scrollbars. xman is an application that uses a viewport widget, as illustrated by Figure 7-20.
Many applications include one or more areas in which you can enter text. All such text entry areas support the same set of editing commands. At this point, xedit, xmh, and several user-contributed clients use the text widget.
In applications (such as xedit) that use the text widget, various Control and Meta keystroke combinations are bound to a set of commands similar to those provided by the emacs text editor.* In addition, the pointer buttons may be used to select a portion of text or to move the insertion point in the text. Pressing the first pointer button (usually the left button) causes the insertion point to move to the pointer. Double-clicking the first button selects a word, triple-clicking selects a paragraph, and quadruple-clicking selects everything. Any selection may be extended in either direction by using the third pointer button (usually the right).
In the following list of commands, a line refers to one displayed row of characters in the window. A paragraph refers to the text between manually inserted carriage returns or blank lines. Text within a paragraph is automatically broken into lines based on the current width of the window.
In Release 4 of X, the following keystroke combinations are defined as indicated. (Note that “Control” and “Meta” are two of the “soft” key names X recognizes. They are mapped to particular physical keys which may vary from keyboard to keyboard. See the “xmodmap” section in Chapter 11. Setup Clients, for a discussion of modifier key mapping.) If you are using an earlier release of X, a few of the following keystroke combinations may produce slightly different results.
*If you are running an earlier release of X, you can operate xcalc as a slide rule by using the
-analog option. You drag the slide using the first pointer button. Be aware that the slide rule mode doesn’t work very well. To terminate the slide rule, use kill(1), as described above for xclock. The slide rule emulation has been eliminated in Release 4.
Help command also opens a large window in which the same help information is displayed. The
Help command is something of a dead end, however. You cannot display any other text in this window.
*This method is powerful, but in practice has limitations. Many versions of UNIX only allow you to kill a process if you are the owner of the process or if you are root. Thus, if a client has been started on your display from a remote system, and you don’t know the root password, you may not be in a position to use the UNIX kill command.
†You can also use the window ID as an argument to the xprop client, which displays various window “properties.” A property is a piece of information associated with a window or a font Properties facilitate communication between clients via the server. They are used by clients to store information that other clients might need to know, and to read that information when it is provided by other clients. See the xprop reference page in Part Three of this guide, and Volume One, Xlib Programming Manual for more information about properties and the xprop client.
*Most likely, you will not have to deal with the ID numbers for windows other than the explicitly named client windows. You can use the IDs of the client windows in all of the ways we’ve discussed: with xkill, xwininfo, xprop, etc.