Optimizing Linux's User Interface

by Jeff Arnholt

One of Linux's most impressive but least recognized features is its flexible and powerful desktop environment. While great efforts are underway to develop the next generation of desktop interfaces (such as OSF's Common Desktop Environment or Microsoft's Windows 95 and Bob), Linux enthusiasts have for years had a choice of several stable, powerful, and customizable window managers and shells for program management.

Unlike many other operating systems, Linux runs extremely well on standard VGA 80x24 terminals. While unglamorous and less intuitive, Linux's terminal interface provides speed and ease-of-use still unmatched by GUIs. Linux uses mature, powerful shells such as tcsh and bash, which elegantly display and manipulate text at blazing speeds on any PC. Linux's text mode support is particularly appropriate for portables with small screens, slower processors, and little memory. [See “The Best without X” in this issue, page 22—Ed]

The reduced requirements for character-mode displays also enables Linux to run very well off of floppy drives, which has great utility for creating bootable emergency repair disks or running Linux on non-Linux PCs. Linux's text mode support is inappropriate for graphical applications like Netscape or WYSIWYG word processors, but is superior for system administration and text editing tasks due to its versatility, speed, and uniform support.

At the other end, Linux supports a wide number of X-Windows servers on large monitors at resolutions up to 1600x1200. Linux's X-Windows client-server technology offers the superb capability of displaying graphical applications locally which run remotely, a feature unmatched by other PC operating systems. X-Windows is also notable for the extreme amount of customization available through resource files. For example, as a left-handed mouse user I commonly switch the scrollbars of my X-Windows applications to the left side, which cannot be done with other operating systems. With native support for three-button mice, multiple displays, and a myriad of free window managers, Linux provides more powerful and flexible desktop interface options than most other operating systems.

Unfortunately, the Linux interface suffers from the inevitable tradeoff of flexibility and power for ease-of-use. Many Linux users continue to use default X-Windows or shell configuration files, unaware of alternative interface tools or configuration options which can simplify or enhance their current setup. I have encountered many Linux users who are unwilling to modify their installation because of arcane configuration file syntax and lack of knowledge on this subject. This problem continues to increase as more people without Unix training migrate to Linux.

This article describes strategies for desktop interface configuration and utilization under Linux. These strategies are based on a simple premise: the optimal desktop environment is one which maximizes data visualization and screen utilization (output) while minimizing the amount of time, interaction, and complexity required to perform a given task (input). Utilities which are frequently used must be immediately accessible to users with a few keystrokes or button clicks. Less commonly used utilities need not be as accessible but should be well-organized such that they are easily located and started. Utilities should optimize screen usage to permit monitoring and interaction with multiple, concurrent processes. Finally, all interface tools must make minimal usage of memory and CPU resources.

Having tested the majority of Linux window managers and shells over the past several years, I am most impressed by rxvt and fvwm, John Bovey's and Robert Nation's (fvwm@wonderland.org) xterm clone and window manager, as tools to manage my desktop environment. I use Tcsh, written by multiple authors, within rxvt, although Bash, GNU's “Bourne again shell”, is a fine alternative.

The Command Line

While I prefer most graphical programs to their command line alternatives (ftptool instead of ftp, for example), terminal windows continue to provide three important uses. First, most of my routine system administration tasks are performed with homegrown perl and shell scripts running in a term window. While many fine GUI program builders are available (such as Tcl/Tk), it is still simpler to program shell scripts for command line input and output. Complex networking, file management, searches, or other system activities are most easily performed in this manner. Second, even as SLIP and PPP become more widespread, wider support and better responsiveness exists for terminal-based serial line communications.

Finally, terminal windows usually provide much faster interaction than GUI alternatives. It is much easier and faster to type “date” at the command line than to open an Xclock (which requires more keystrokes), move it and/or minimize it, read it, and then close it. In addition, programs which do not require much user interaction are best run as command-line applications to avoid the additional resources and programming complexity required by graphical applications. Linux's terminal windows serve as master interfaces for all programs without sophisticated input/output requirements and eliminate the need to open multiple windows for different tasks.

Rxvt

I prefer rxvt to xterm as an X-Windows terminal emulator. Rxvt provides a subset of common xterm features with substantial memory savings. The amounts of physical memory required by xterm and rxvt, as reported by top (a program that displays CPU activity), are 2120KB and 560KB, respectively. Since I commonly run three to four X-Windows terminal sessions simultaneously, I save approximately 6MB of memory by using rxvt. Rxvt does not support Tektronix 4014 emulation or session logging, but this is seldom a concern.

Tcsh

Tcsh has enough features to merit another article, so I will concentrate on just a few aspects with respect to its user interface functions. Most notable is its excellent support of Emacs-style command line editing. Typographical errors are easily corrected by moving the cursor to the error with the arrow keys and using editing commands such as ctrl-D or ctrl-K to make the modification. Previous commands can be edited in the same fashion by first scrolling back through the history list using the up arrow. Filename completion is enabled by putting set filec in .cshrc (the tcsh configuration file located in the user's home directory), which enables the user to type in just a few characters of a long filename and press tab to complete the remainder (assuming those characters are unique). This feature has become so useful and natural to me that I find myself constantly pressing tab in situations which do not support it, such as remote ftp session or when I need to work under MS-DOS. As an example, If I want to view the contents of text file OptimizingLinuxUserInterface, I simply type cat Opttabreturn, and the filename is completed for me—unless there is another file with those first three characters. In that case, I need to supply additional characters.

Tcsh also has advanced ways to set the prompt, which I use to keep track of the present working directory (indentation is important). From my .cshrc:

:set prompt = '\n%B%n@%m%b:%/ %h %# '

gives: root@regal:/home/root 27 #

when working as the user root on the machine regal in the directory /home/root with a current history command number of 27.

I also like the ctrl-alt-Z shortcut tcsh provides to allow me to jump from the shell to a suspended version of Emacs and ctrl-Z to bring me back to the shell. It has eliminated my dependence on Emacs's internal shell, which displays some non-standard behavior regarding key assignments.

Having been accustomed to command.com for many years, my favorite feature of tcsh and other Unix shells are aliases. As have most Linux users, I've aliased extremely common commands such as ls, ls -l, rlogin, and less to l. ll, r, and t (short for type). This is easily done in .cshrc with lines like

alias rlogin 'lr'

Here are a few useful and representative selections from my .cshrc for file viewing, process logging, telnet access, floppy formatting, and remounting the hard drive if it boots read-only (note: the last one comes up all the time frantically in Usenet's comp.os.linux hierarchy).

:
alias t           'expand -5 \!* | less'
alias pss         'ps -au | grep $user | less'
# Syntax: pss <user>
alias archie      'telnet archie.internic.net'
alias formatfd0   'echo "Using ext2 filesystem."
                   fdformat /dev/fd0H1440;
                   mkfs -t ext2 /dev/fd0H14440'
alias remountroot  'set temp = $PWD; cd /;
                   mount -w -n -o remount /;
                   cd $temp'

Excellent shell tools such as tcsh and rxvt are one reason why I consider Linux's interface to be superior to most non-Unix operating systems. DOS, Windows, NT, and even the Mac do not offer this powerful and fast means for program and system interaction.

Fvwm

Fvwm is an excellent choice for a window manager, providing most or all of the functionality of Motif in far less memory (like rxvt compared with xterm). Fvwm was derived from twm code, but designed to use fewer system resources. Informal tests with top show that fvwm uses 700KB of physical memory (RSS) compared to OpenLook's 900KB, twm's 1700KB, and mvwms's (Motif) 1900KB. Not even the author still remembers what fvwm stands for, although I've often heard “feeble virtual window manager”. This is an unfortunate name, since fvwm is far from feeble. [I suggest that this is why the author chooses not to remember what it stands for. —Ed]

Fvwm employs a virtual desktop like olvwm with a maximum size of 32KB pixels squared (I doubt anyone would ever take advantage of such gargantuan proportions), and has a look and feel very similar to Motif. Sticky windows can be assigned which stay on the screen regardless of which virtual desktop is currently being viewed. As with Motif, resizing windows invokes a helpful grid showing the changing dimensions of the window. Shaped windows are supported, but increase memory utilization by 60KB (I don't use these).

Fvwm utilizes “modules”, a concept not shared by other window managers. Modules are separate programs which may be independently developed, yet which are integrated into fvwm. Modules run as separate Linux processes, spawned by fvwm such that a pair of pipes are used to transmit commands back and forth for execution. While this design may be superior for window manager programming, it is particularly important to the average Linux enthusiast because it provides more functionality than most window managers.

Fvwm's man page is very long (36 pages) and complete. More important, the sample configuration file which comes bundled with fvwm is crammed with comments and useful defaults. Fvwm is like other window managers or X-Windows applications in that great control may be exercised over almost every aspect of display. Window color, border size, and window behavior are easily specified in the .fvwmrc or .Xdefaults file. Specific directions for such modifications are available in the default .fvwmrc file. Configuring fvwm should not be difficult.

I find that the most useful desktop interface feature offered by fvwm (and most other window managers) is its root menu. Customization of the root menu provides easy access over almost every aspect of the system. On my Linux workstation, the first five root entries (Apps, Docs, Desktop, Network, and System) are pointers to submenus.

Apps contains all productivity X-Windows applications, like xemacs, xv, etc.

Docs are common ASCII documents which I constantly need to access, such as my to-do list. I also use this submenu to organize the many, many ASCII configuration files used by Linux. Since I have Emacs running at all times, the .fvwmrc statement controlling this entry runs emacsserver:

Exec "To do list" exec emacsclient /home/root/todo &

Emacsserver then loads the running Emacs with my document and switches buffers to display the new document. This method saves memory and minimizes the number of windows on my screen.

Desktop modifies the appearance of the screen and is used to invoke screen savers and change backgrounds. For example, I can call each of the different xlock screen savers in my .fvwmrc with:

Popup "DesktopScreensavers" Exec "Fractal Flame" exec xlock -nolock -nice 0 -mode flame & Exec "Game of life" exec xlock -nolock -nice 0 -mode life & ... EndPopup

I can load and automatically expand any graphic to serve as background wallpaper with:

Exec "Starry skies" xv -root -max -quit /data/wallpaper/VanGogh1.jpg

or create a texture (a small graphic which may be tiled to give an interesting background) with:

Exec "Red brick wall" xv -root -quit /data/wallpaper/redbrick.jpg

Network runs any of the common browsers or utilities, such as FTP, Archie, Gopher, etc. I also use this menu to access the different network daemons currently running.

System lists a wide variety of utilities involved with system administration. For those of you familiar with Windows 3.11, this entry is similar to, but substantially more powerful and customizaable than, the control panel applet. One entry in the submenu runs my perl backup script in a new rxvt window; another opens the excellent keyboard mapping utility xkeycaps:

Exec "Keyboard mapping" exec xkeycaps -keyboard DELL &

Other entries in my root menu start the screen blanker (I have a Nokia monitor which powers down upon receiving a black screen), refresh the window, and exit fvwm.

For an excellent (albeit expensive) reference to extensive root menu customization, see The Shell Hacker's Guide to X and Motif by Alan Southerton.

GoodStuff

The GoodStuff iconbar is truly one of the most useful Linux utilities I have ever found. GoodStuff is a fvwm module and only runs under fvwm. GoodStuff is an iconbar extremely similar to that found on the NeXT and to a lesser extent like Window's Dashboard or RipBAR. GoodStuff uses approximately 500KB of memory and very little CPU resources. The configuration file is the same as fvwm, .fvwmrc.

GoodStuff's primary use is simply to assign iconic buttons to commonly-used applications so that they may be started with a single mouse click. For example, I have rxvt terminals assigned to each machine in my home network which I can immediately log into. This is substantially faster than my old method of typing xterm, moving the mouse into the window's field of view, clicking for focus, typing rlogin machine name, and then entering my password.

I also have common utilities, such as my mail utility, ftptool, Emacs editor, netscape, file manager, and so forth attached to individual buttons. I limit the GoodStuff iconbar to a dozen buttons (laid out in a 2'6 matrix), because each one takes valuable screen real estate, especially since I have it set permanently in the foreground. Rxvt, my most commonly started application, is not included in GoodStuff but instead is mapped to the middle mouse button on the root window. I can immediately pop up a new rxvt window by simply clicking the second button on the background wallpaper. Less commonly used programs are attached to the root menu (as described in the previous section).

Button bars are hardly novel. What is special about GoodStuff is that one may assign running X-Windows applications to each button and use the button as the display. For example, I have xload running as a 2x1 button at the top of the GoodStuff menubar, and it displays just as it would in a small window. I have xbiff in another window, which alerts me if mail has arrived (the button's color becomes inverted, and it is very noticable). I even have a less well-known but equally useful X-Windows app called xosview which monitors instantaneous CPU, memory, disk, and network usage as a small colored bar graph. It is very helpful for me to watch this program running in the GoodStuff button bar to see when I'm taxing the network or CPU or running out of memory or disk space. All I needed to do to incorporate xosview into GoodStuff was the following line in the .fvwmrc:

*GoodStuff - whatever Swallow "xosview" xosview -bg grey -geometry 210x96-1500-1500 &

I also have fvwm's 2x2 virtual desktop at the bottom of the GoodStuff menu bar. I don't use it all that often, but it is a handy feature when needed.

Other fvwm modules exist, including Pager, Banner, WinList, Clean, Ident, Save, Scroll, Debug, and Sound. I don't use them as much as GoodStuff, but they are all useful utilities.

Conclusions

The strategy described above uses fvwm, tcsh, and other utilities to generate an effective desktop interface to manage programs, data, and system resources. While lacking in certain features, such as drag-and-drop desktop tools and object-oriented metaphors, the combination of these tools creates a desktop which is more flexible, customizable, and powerful than competing paradigms. Current versions of these tools are freely available at many Internet sites including ftp://sunsite.unc.edu/pub/Linux.

Jeff Arnholt is currently developing X-based biomedical imaging packages at the Mayo Clinic in Rochester, Minnesota. He is a medical and graduate student who hopes to earn his MD/PhD degrees by 1997. You may contact him at arnholt@mayo.edu.

Load Disqus comments