start page | rating of books | rating of authors | reviews | copyrights

Running Linux, 4th Ed.Running Linux, 4th Ed.Search this book

11.6. Other X Applications

In this section, we will cover some material about X applications that are neither KDE nor GNOME applications. As should be clear by now, you can run these in any of the desktop environments without problems, even though they might not be as integrated.

We'll particularly spend some time with one aspect of older X applications: X resources, a very powerful, but also confusing and difficult-to-learn way of customizing X applications.

Before we tackle the X resources, one more hint: many programs described elsewhere in this book are X applications as well and are run in an X environment (whether it is KDE, GNOME, or something else), just like the programs described here. And there are literally tens of thousands more out there on the Net — yours to discover!

11.6.1. The X Resource Database

If you aren't running a desktop or if you have to deal with applications that aren't well integrated into your desktop, you will be asked to deal directly with X resources; they are mentioned in virtually every manual page. X resources provide a more flexible and powerful way to configure X clients than using command-line options, such as -geometry and -fg. They allow you to specify defaults for entire classes of clients; for example, we could set the default font for all invocations of xterm to 7x13bold, instead of specifying it on each command line.

Recently, X resources have fallen out of favor with X developers. While they are really very flexible, they are not particularly easy to work with and feel more like a relic of ancient times. A growing number of programs are therefore customized not by X resources but instead via convenient configuration dialog boxes. However, it still pays to know about X resources because you will meet them for a long time to come.

Using X resources requires two steps. First, you create a file containing your X resource defaults. Typically, this file is called .Xdefaults and lives in your home directory. Then, you need to use xrdb to load the X resources into the server, which makes them available for use. In general, you run xrdb from your .xinitrc before starting any clients.

As a simple example, let's take the various command-line options used by the clients in the earlier sample .xinitrc and specify them as X resources instead. Afterward, we'll show you what kinds of changes need to be made to .xinitrc to make use of the resources.

First, a few words about resources and how they work. Each X application is part of a certain application class. For example, xterm is a member of the XTerm class. xclock and oclock are both members of the Clock class. Setting resources for the Clock class affects all applications that are part of that class; because xclock (a square analog clock) and oclock (an oval analog clock) are similar, they belong to the same class and share the same resources. Most applications are members of their own exclusive class; xload is the only member of the XLoad class. However, if another xload-like application were to be written, it might be part of the XLoad class as well. Placing X clients into application classes allows you to set resources for all applications in that class. (The manual page for each X client specifies the application class to which the client belongs)

Standard X clients employ resources such as foreground, background, geometry, and font. Also, many X clients have specific resources of their own; for example, xterm defines the resource logFile, which allows you to specify a file in which to log the terminal session. Again, the manual pages for X clients specify which resources are available.

Moreover, resources themselves are arranged into a hierarchy of classes. For instance, the background resource is a member of the Background class. Resource classes allow many separate resources to be members of the same class, for which you can set resource values for the class as a whole. For example, the background resource usually determines the primary background color of a window. However, if an application window has several panels or regions, you may wish to set the background for each panel separately. There might be resources such as background1, background2, and so on, for each panel, but they would all be members of the Background resource class. Setting the resource value for the Background class sets the value for all resources in that class.

In general, you won't need to concern yourself with the differences between resource classes and the resources within that class. In most cases, it's easier to set resource values for an entire class (such as Background) instead of individual resources in that class.

Now, let's look at how resource values are set in the X resource database. A complete resource specification is of the form:[44]

[44]Actually, resource specifications have a more complex syntax than this, and the rules used to determine resource and value bindings are somewhat involved. For simplification, we are presenting a reasonable model for application resource settings — and we direct curious readers to a good book on using X, such as the X Window System User's Guide.

            (ApplicationClass|applicationName)*(ResourceClass|resourceName) : value

The vertical bar means "choose one or the other." Let's say you want to set the background color of an xterm window. The complete resource specification might be:

            xterm*background: darkslategray

However, this sets only a particular background resource (not all the resources that might be in the Background class) and only for the xterm client when it is invoked as xterm (more on this later). Therefore, we might want to use resource classes instead:

            XTerm*Background: darkslategray

This resource specification will apply to all xterm clients, and all Background-class resources used by xterm.

Now, let's look at translating the options given in the earlier .xinitrc file into application resources. Create a file in your home directory, called .Xdefaults. For the previous sample .xinitrc, it should contain:

            1  Clock*Geometry:         70x70+5+5
            2  XLoad*Geometry:         85x50+85+5
            3  XBiff*Geometry:          +200+5
            4
            5  ! Defaults for all xterm clients
            6  XTerm*Foreground:       white
            7  XTerm*Background:       black
            8
            9  ! Specific xterms
            10 xterm-1*Geometry:       80x40+10+110
            11
            12 xterm-2*Geometry:       -20+10
            13 xterm-2*Font:           7x13bold
            14 xterm-2*Background:     darkslategray
            15
            16 xterm-3*Geometry:       80x25-20-30
            17 xterm-3*Font:           7x13bold

Lines 1-3 set the Geometry resource class for the Clock, XLoad, and XBiff application classes. On lines 6-7, we set the Foreground and Background resource classes for the XTerm class as whole. All xterm clients will use these values for Foreground and Background by default.

On lines 10-17, we set resources specific to each invocation of xterm. This is necessary because not all the xterms are alike; they each have different geometry specifications, for example. In this case, we have named the individual xterm invocations xterm-1, xterm-2, and xterm-3. As you can see, we set the Geometry resource for each on lines 10, 12, and 16. Also, we set the Font class for xterm-2 and xterm-3. And we set the Background class to darkslategray for xterm-2.

X resource binding rules work so that certain bindings have precedence over others. In this case, setting a resource for a specific invocation of xterm (as in xterm-2*Background on line 14) has precedence over the resource setting for the XTerm class as a whole (XTerm*Background on line 7). In general, bindings for an application or resource class have lower precedence than bindings for particular instances of that class. In this way, you can set defaults for the class as a whole but override those defaults for particular instances of the class.

Now, let's look at the changes required to .xinitrc to use the X resources defined here. First, we need to add an xrdb command, which loads the application resources into the server. And, we can get rid of the various command-line options that the resources have replaced, as in:

            #!/bin/sh
            # Sample .xinitrc shell script

            # Load resources
            xrdb -load $HOME/.Xdefaults

            # Start xterms
            xterm -name "xterm-1" &
            xterm -name "xterm-2" &
            xterm -name "xterm-3" &

            # Other useful X clients
            oclock &
            xload &
            xbiff &
            xsetroot -solid darkslateblue &

            # Start the window manager
            exec fvwm2

As you see, the -name argument given to the three instances of xterm lets us specify the application name that xterm uses for locating X resources. Most X clients don't support a -name argument; the name used is usually the one with which it was invoked. However, because many users run several xterms at once, it is helpful to distinguish between them when setting resources.

Now, you should be able to modify your X environment to some degree. Of course, knowing how to configure X depends partly on being familiar with the many X clients out there, as well as the window manager (and how to configure it).

11.6.2. Emacs and Other Editors

The X features in Emacs are getting spiffier and spiffier. They include pull-down menus, different typefaces for different parts of your window, and a complete integration of cut-and-paste functions with the X environment.

TIP: Most distributions nowadays also carry XEmacs, a version of Emacs that integrates even better into the X Window System and has a much nicer and more user-friendly appearance. You might want to try it out. Most of the concepts here apply to XEmacs, too.

Let's start by defining some nice colors for different parts of the Emacs window. Try this command:

          eggplant$ emacs  -bg ivory  -fg slateblue  -ms orangered  -cr brown

You're setting the background color, foreground color, mouse color, and cursor color, respectively. The cursor is the little rectangle that appears in the window, representing what's called "point" in Emacs — the place where you type in text. We'll return to colors soon.

When you start Emacs, the menu bar on top and the scrollbar on the right side of the window stand out. See Figure 11-10.

Figure 11-10

Figure 11-10. Emacs window

The scrollbar works just like the xterm scrollbar. The menu bar offers a lot of common functions. Some editing modes, such as C and TEX, have their own pull-down menus. The menus are not documented, so you will just have to experiment and try to figure out which Emacs functions to which they correspond.

When you want to use a function that doesn't have a simple key sequence — or you've forgotten the sequence — the menus come in handy. For instance, if you rarely use a regular expression search (a quite powerful feature, well worth studying), the easiest way to invoke it is to pull down the Edit menu and choose Regexp Search.

Another useful menu item is Choose Next Paste on the Edit menu. This offers something you can't get any other way: a list of all the pieces of text you've cut recently. In other words, it shows you the kill ring. You can choose the text you want to paste in next, and the next time you press C-y, it's put into your buffer.

If you get tired of the scrollbar and the menu, put the following LISP code in your .emacs file to make them go away:

          (if (getenv "DISPLAY")
          (progn (menu-bar-mode -1)
          (scroll-bar-mode -1))
          )

The mouse is the next X feature with interesting possibilities. You can cut and paste text much the same way as in xterm. And you can do this between windows; if you see some output in an xterm you'd like to put in a file, you can copy it from the xterm and paste it into your Emacs buffer. Moreover, any text you cut the normal way (such as through C-w) goes into the same selection as text you cut with the mouse. So you can cut a few words from your Emacs buffer and paste them into an xterm.

The right mouse button works a little unusually. If you select text with the left mouse button, you can click once on the right mouse button to copy it. A second click on the right mouse button removes it. To paste it back, press the middle mouse button. The text goes just before the character the mouse is currently on. Make a mistake? That's all right; the undo command reverses it just as for any other Emacs function. (Choose Undo from the Edit menu or just press the C-_ key.)

If you really love mouse work, you can define the buttons to execute any functions you want, just as with keys. Try putting the following command in your .emacs file. When you hold down the Shift key and press the left mouse button, a buffer for composing a mail message appears:

          (define-key global-map [S-mouse-1] 'mail)

We don't recommend you redefine the existing mouse functions, but the Shift, Control, and Meta keys offer plenty of unused possibilities. Combine S-, C-, and M- any way you want in your definitions:

          (define-key global-map [S-C-mouse-1] 'mail)

Now let's play around a bit with windows. Emacs has had windows of its own for decades, of course, long before the X Window System existed. So an Emacs window is not the same as an X window. What X considers a window, Emacs calls a frame.

How would you like to edit in two frames at once? Press C-x 5 2, and another frame appears. The new frame is simply another view onto the same editing session. You can edit different buffers in the two frames, but anything you do in one frame is reflected to the corresponding buffer in the other. When you exit Emacs by pressing C-x C-c, both frames disappear; if you want to close just one frame, press C-x 5 0.

To end our exploration of Emacs on the X Window System, we'll look at the exciting things you can do with colors. You can change these during an Emacs session, which makes it easy to play around with different possibilities. Press M-x, then type set-background-color and press the Enter key. At the prompt, type ivory or whatever other color you've chosen. (Remember, Emacs uses the convention M-x where we use Meta-x or Alt-x in the rest of the book.)

Be careful to make the foreground and background different enough so that you can see the text! In addition to set-background-color, Emacs offers set-foreground-color, set-cursor-color, and set-mouse-color.

Before finishing up this section, we would also like to mention that if Emacs or XEmacs is a bit too much for you, you will be delighted to know that KDE comes with a variety of text editors that range from quite simple to quite sophisticated. None of these is as big or powerful as (X)Emacs, but any of these may do the trick.

The three KDE text editors are called (sorted from least to greatest sophistication) KEdit, KWrite, and Kate, where the latter stands for KDE Advanced Text Editor. Kate can be used as a full-blown programmer's editor with syntax coloring, multiple files opened at the same time, etc. KEdit is similar in feature richness (or poverty) to the Notepad editor on Windows systems, and KWrite is somewhere in-between. You will find all three of them in the K menu, under the submenu Editors.



Library Navigation Links

Copyright © 2003 O'Reilly & Associates. All rights reserved.