Chapter 7. Running X Clients

Running X Clients

Running an X client is generally a fairly simple proposition, but it is different from running a character application. This chapter covers:

  • Running clients in the background (Section 7.2)

  • Requesting a certain window size and position (Section 7.3)

  • Running nongraphical programs on an X display (Section 7.4)

Displayspecs (Section 1.12) are a closely related topic.

Background Operation

Most X applications don’t need to interact with the user through the standard input and output; therefore, when starting them from a shell prompt, you may as well put them into the background. Simply add an ampersand to the end of the command name:

	$ kcalc &

If you close the terminal from which you started the client, the client will (in almost all cases) be terminated. To avoid this, use the nohup command:

	$ nohup kcalc &

Tip

Some error messages may be sent to standard error, which may not be visible when the client is run in the background. When debugging the operation of a client, it may be necessary to redirect stdout and stderr to a file:

	$ nohup kcalc >kcalc.log 2>&1 &

Geometry

In X Window parlance, geometryrefers to the size and position of windows. Clients may request a particular geometry when placing a new window, but the window manager can override the request and force another geometry.

The units used for window size vary by application. Terminal windows, for example, are usually sized in text rows and columns (for example, 80 x 24 or 132 x 44); many applications, such as Firefox, are sized in pixels; and others, such as theGimp, use arbitrary units of the programmer’s choosing.

The xwininfo command (Section 6.3) will display information about a window’s current geometry:

	$ xwininfo
	xwininfo: Please select the window about which you
	          would like information by clicking the
	          mouse in that window.
	...User clicks on a terminal window...
	xwininfo: Window id: 0x36059c4 "chris@concord2:~"

	  Absolute upper-left X: 485 
	  Absolute upper-left Y: 59
	  Relative upper-left X: 6
	  Relative upper-left Y: 20
	  Width: 710
	  Height: 538
	  Depth: 24
	  Visual Class: TrueColor
	  Border width: 0
	  Class: InputOutput
	  Colormap: 0x20 (installed)
	  Bit Gravity State: NorthWestGravity
	  Window Gravity State: NorthWestGravity
	  Backing Store State: NotUseful
	  Save Under State: no
	  Map State: IsViewable
	  Override Redirect State: no
	  Corners: +485+59 -85+59 -85-427 +485-427
	  -geometry 77x34-79+39

Note that the geometry specification (or simply, geometry)is 77x34-79+39, but the width is 710 pixels and the height is 538 pixels!

The geometry specification is in this form:

          WIDTHxHEIGHT XPOSITION YPOSITION

where the following definitions are true:

WIDTH

The window width in the increments used by the application

HEIGHT

The vertical height of the window in the increments used by the application.

XPOSITION
YPOSITION

The horizontal and vertical coordinates of the upper-left corner of the window frame, including any window border, title bar, or other ornamentation added by the window manager. If these numbers start with a plus sign (+), then they are relative to the upper-left corner of the screen; if they start with a minus sign (-), then they are relative to the lower-right corner of the screen.

Therefore, the geometry shown in the earlier example, 77x34-79+39, is interpreted as meaning that the window should be 77 units high and 34 units wide, and the upper-left corner of the window should be 79 pixels left from the right side of the screen and 39 pixels down from the top of the screen.

Tip

You can use both + and - on the same geometry positioning expression. The first sign indicates the starting corner (upper-left or lower-right), and the second is used to indicate the sign of the value. Therefore, a geometry specification of 200x200+-100+50 specifies a window size of 200 x 200, and a window starting off the screen 100 pixels to the left of the screen’s left edge and 50 pixels from the top.

But what is the unit of measure for the size? We can determine that by giving xwininfo the -size option:

$ xwininfo -size

	xwininfo: Please select the window about which you 
	          would like information by clicking the 
	          mouse in that window.
	...User selects the window...
	xwininfo: Window id: 0x36059c4 "chris@concord2:~"

	  Normal window size hints:
	      Program supplied minimum size: 53 by 58
	      Program supplied base size: 17 by 28
	      Program supplied x resize increment: 9
	      Program supplied y resize increment: 15 
	      Program supplied minimum size in resize increments: 5 by 3
	      Program supplied base size in resize increments: 1 by 1 
	      Program supplied window gravity: NorthWestGravity 
	No zoom window size hints defined

Here we can clearly see that the window has set the size increment to 9 pixels horizontally and 15 pixels vertically. Therefore the width of the window is 77*9=693 pixels, and the height is 34*15=510 pixels. We can also see that the minimum window size is 5*9=45 pixels, and the minimum height is 3*15=45 pixels.

Many applications allow you to specify the geometry on the command line. The option is -geometry for applications that use Xt-based toolkits (Athena and Motif), or it’s --geometry for GTK+ and Qt-based applications.

These commands all open up a 25-line, 80- character-wide terminal window, located 100 pixels below the top of the screen and 50 pixels to the right of the left edge of the screen:

	$ gnome-terminal --geometry 80x25+50+100 # GTK+
	$ konsole -geometry 660x475+50+100 # Qt
	$ xterm -geometry 80x25+50+100 # Xt

Notice that the konsole size is specified in pixels, which the xterm and gnome-terminal sizes are specified in characters.

Split Personality: Running Nongraphical Applications

From before X was released up to a few years ago, character terminals were in wide-spread use. These devices had a character-only display, typically 80 columns wide by 24 or 25 rows high, and a keyboard. Each model of terminal varied in its display capabilities—some had color, some offered varying font sizes for 132- and 40- column display modes, and some could draw underlined and bold text—and in its keyboard layout. These terminals were typically connected to the host computer through a serial cable, which required as little as 3 wires and could be over 100 meters long (300 foot). Modems, designed to work with serial interfaces, could be used to extend this distance over the dial-up telephone network.

Many applications have been written with a character-based interface intended for use with a terminal. Standard utilities such as cp, mv, and ls, and server programs such as Apache just write plain text to standard output and standard error; other programs—including many editors (vi, Emacs, Joe, and Pico) and applications such as Midnight Commander and Pine—take over the full terminal screen, sending sequences of control characters to position text and control the display attributes.

These full-screen programs use a curses library, which looks up the terminal type in a database to determine its capabilities, the codes used to control those capabilities, and the special codes that may be received from the keyboard (for example, when a function key is pressed). The terminal type is retrieved from the environment variable TERM.

In addition to controlling the terminal using curses, character applications also control the characteristics of the serial line connected to the terminal, such as whether characters that are typed are echoed back to the display (which is the case when using a shell) or not (when entering a password). These attributes are configured using the operating system’s termios interface.

X by itself is incompatible with all applications character-based applications. The X server does not provide a termios interface and cannot be configured to understand the types of control codes emitted by curses.

In order to bridge this gulf and use character-based programs with X, it is necessary to use a two-sided application that presents a termios interface on one side and is a client to an X server on the other side. This application must translate incoming X events: keypress events are translated into ASCII sequences, window closure is translated into a modem hangup signal (SIGHUP), and so forth. Likewise, it must emulate termios operations such as echo management and translate curses code sequences into the appropriate X protocol commands.

These applications are known as terminal emulators. The granddaddy of them all is xterm, which has been distributed with X11 since it was first released. Various terminal emulators have been developed to extend or improve on xterm, including rxvt, wterm, and eterm. Each of the major desktop environments also includes a terminal emulator: GNOME has gnome-terminal and KDE has konsole.

Most of the Unix/Linux terminal emulators used with X understand the same codes as the original xterm program, and therefore are usually used with the TERM environment variable set to xterm (since the xterm codes are based on those used by the DEC VT102 terminal, which were later standardized in ANSI X3.64, the value vt102 or ansi is sometimes used).

Tip

In addition to the ASCII- based terminal emulators discussed here, most X installations also include x3270, which is an IBM EBCDIC-based terminal emulator that is used with mainframes. Another common emulation is IBM 5250, which is also EBCDIC-based and is used with IBM i-Series systems (formerly AS/400s).

As shown in Table 7-1, xterm, konsole, and gnome-terminal have similar command-line options to set the terminal window name, the TERM variable value, and the program to be executed on the terminalinterface side (the default is the $SHELL). These programs may be extensively customized using resources (in the case of xterm) or named settings profiles (in the case of gnome-terminal and konsole).

Table 7-1. Basic command-line options for common terminal emulators

Description

xterm

gnome-terminal

konsole

Program to be executed

-e

-e

-e

Window title

-T

-t

-T

TERM environment variable value

-tn value

(TERM value is always xterm)

--tn value

These three commands all run vi in a terminal window with the title set to Vi Editor:

	$ xterm -T "Vi Editor" -e vi
	$ gnome-terminal -t "Vi Editor" -e vi
	$ konsole -T "Vi Editor" -e vi

Note that the window title can be changed by emitting a control code sequence. The sequence is:

	ESC ] 0 ; text BEL

where ESC and BEL are the corresponding ASCII codes (27 and 7 in decimal, 033 and 007 in octal, 0x21 and 0x7 in hexadecimal), and text is the text that should be presented in the title bar. Therefore, to set the title to MyWindow, you could execute the following:

	$ echo -e "33]0;My Window07c"

When using bash, you can set the PROMPT_COMMAND environment variable to a command that should be executed before each prompt is printed. This is often set to show useful information, such as the current directory, using a command such as this:

	$ export PROMPT_COMMAND='echo -e "33]0;${PWD}07c"

You can also set the title bar in the prompt:

	$ export PS1="e]0;$USER@$HOST: $PWDa$ "

If you’re using csh, the cwdcmd, precmd, and postcmd aliases enable you to execute a command after each directory change, before each prompt is printed, or after each command is entered, respectively. To update the window title to the current directory after each directory change:

	% alias cwdcmd 'echo -n "^[]0;$cwd^G"'

To enter the ^[ in this line, press Ctrl-V, ESC; to enter ^G, press Ctrl-V, Ctrl-G. Or, if you’re using tcsh and have echo_style set to both, you can type e in place of ^[ and a in place of ^G.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
13.58.232.95