Customizing X Window Sessions with fvwm
Richard L. Brownrigg The X Window system has a number of mechanisms that give the user the ability to customize the "look and feel" of their X Window sessions. Making use of these features unfortunately requires a level of sophistication and knowledge of X Window that is beyond the casual user. Often the systems administrator must configure the X environment on the users' behalf. Of the various mechanisms, window managers exert the greatest influence on the overall look and feel of the graphical environment. X Window provides the underlying capabilities, while the window manager brings the "desktop metaphor" of graphical interaction to life. It defines the gestures by which overlapping windows are manipulated, mediates cooperation between multiple applications, moderates their conflicting demands, and directs user inputs appropriately. fvwm is a freely available, highly portable window manager that permits customization of even the most minute elements of the interface. Additionally, fvwm offers a number of extensions not typically found in other window managers, such as support for independent desktops composed of virtual screens, creation of button panels with customizable behavior, and use of multicolored pixmaps as icons, buttons, and in menu items. There is also extensive support for keyboard accelerators, to the point at which windowing operations may be completely mouseless. Alternatively, if standardization rather than customization is the goal, fvwm can be made to emulate the look of other window managers, particularly mwm -- the Motif window manager. Altogether, it is possible to create a graphical environment that can greatly simplify the operational issues for novice users, or give greater control to the more advanced user. fvwm was originally developed by Robert Nation, who began with twm as the basis of his efforts. More recently, the project has been taken over by Charles Hines as developer and manager. Along the way innumerable others have contributed. The combination of an active user community, ready availability, and a central repository is significant because it tends to promote robustness, continued growth of the software, and ultimately widespread acceptance and confidence that the software will be supported in some fashion. The primary web site for fvwm is:
http://www3.hmc.edu/~tkelly/docs/proj/fvwm.html
where links for obtaining the source distribution may be found. There are also links to FAQs, mailing lists, and various other related documents and sites. The official version of fvwm is now 1.24r; however, the next official release will be version 2.1.0, and it represents a major redesign and advancement of features. Version 2, which has been in development for some while and at the time of writing, is currently at version 2.0pl35 (technically considered a beta release). Either release can be obtained, but I recommend starting with version 2 because it represents the direction of future growth, and there are incompatibilities between the configuration files for the two major versions. I have found version 2 highly stable and robust, and I used it as the basis for this article. Building the window manager is straightforward. However, if you elect to incorporate support for multicolored pixmaps (which I encourage), then the Xpm library must also be present. Xpm itself is easy to build and can be obtained from ftp.x.org (or any mirror site) under /contribs/libraries. The fvwm installation is clean and can be isolated for those wishing to experiment and learn first. Fairly comprehensive man pages are included. I have built the package successfully for Linux systems and both Solaris 2.x for x86 and SPARC, and the documentation asserts that fvwm will run on virtually all other platforms as well. Configuring the Window Manager Although the supplied default configuration for fvwm is pretty decent and certainly a good starting point, the real fun and utility comes from customizing the extensive set of configurable parameters. Like most window managers, fvwm's specific behavior is determined by the contents of a file that is read when the window manager is launched. But before discussing the structure of the configuration file, another aspect of fvwm's design the external modules is worth mentioning. fvwm's overall set of behaviors is defined both by its built-in commands and an attendant set of external modules. Modules are separate UNIX processes, launched directly by the window manager, that may run for the duration of the entire X session, or can be executed in response to some event to perform their task and terminate immediately. Interprocess communication is accomplished via pipes, through which a simple text stream of the built-in commands is passed. fvwm is informed of the modules' existence through the configuration file. Thus, modules provide a mechanism to extend the behavior of the window manager, whereby an ambitious programmer can create custom modules to implement new or alternative functionality. The modules distributed with fvwm are listed in Table 1. Some of them perform relatively simple tasks; the more interesting modules are FvwmButtons and FvwmPager, which are discussed in more detail below. The built-in commands implement the base behavior of the window manager. They may be categorized loosely as commands that set global appearances or behavior, commands that cause immediate action on specific windows, and commands that define the external environment, shown in Table 2a, Table 2b, and Table 2c. The configuration file is aptly named .fvwmrc. fvwm searches for it first in the user's home directory, and if not found there, in the .../lib/fvwm directory where fvwm was installed. The structure of the configuration file is fairly loose, requiring no particular ordering. Commands are given along with their parameters, one per line. Commands that configure modules begin with "*"; all others are presumed to be built-in commands or user-defined functions. Lines beginning with "#" are comments. Thus, all configurations are performed in one well-defined place a feature introduced with version 2 of fvwm, which is not the case with prior versions. Listing 1 shows an example configuration file, a slightly modified version of the default configuration. I will refer to it by line number here. Figure 1 is a screen dump of a session using this configuration file. Virtual Screens and Desktops For many people, the main reason to consider fvwm is its support for virtual screens. Most users agree that monitors are perpetually too small, no matter how large the diagonal and the resolution. fvwm offers several techniques for coping within these cramped confines of physical displays. Here, the phrase virtual screen simply means a logical screen that is larger in resolution than the physical screen of the X display. fvwm specifies the virtual screen size in integer multiples of the physical screen. Line 17 of the example configuration shows usage of the DesktopSize built-in command, which in this case specifies a virtual screen that will have twice the resolution of the physical screen in both directions. In general, one can specify an arbitrary NxM virtual screen. Moving through virtual space is described below. fvwm also supports multiple, independent virtual screens, termed "desktops." All of the desktops defined must be of the same virtual screen size, but are otherwise distinct work spaces. Thus there is a hierarchy of spaces within which to organize and layout windows, from physical screen, to virtual screen, to desktop. The man pages suggest one possible use for desktops might be to dedicate a separate desktop to each project or distinct application area. For more information, see sidebar "How Do You Use More Than One Desktop?" The Pager The Pager is a module that displays a small, schematic view of the virtual screens. It imposes a spatial relationship between the desktops, and provides a visualization of both the layout of windows within screens and the user's current position within the overall space. In the intended usage, the Pager typically occupies a fairly small screen footprint, and is visible across all desktops (i.e., it is "sticky"). Figure 2 shows the Pager as configured in our running example. The four desktops are defined at lines 49-52 and organized as a single row by line 211. Notice that each desktop is a virtual screen of dimensions 2x2. At line 48, the location for our Pager is given as the upper right corner of the screen. Titles, colors, and fonts are assigned in lines 44-48, and line 96 endows the Pager window (and all fvwm modules) with "stickiness." In general, the desktops may be arranged as a row, as a column, or within an NxM grid. Both the Pager and the button panel, described below, are invoked for the duration of the X session by the predefined user functions shown at lines 210-217. These functions are in turn executed at startup and restart events, respectively. The Pager provides plenty of visual feedback as to the user's location within virtual space. Small shaded blocks are displayed that represent the windows instantiated on each virtual screen. The blocks are proportionally sized and positioned, and colored the same as the corresponding window frames. The title bar of the active desktop is shaded, as is the background of the currently displayed virtual screen within that desktop. Thus, at a glance, users can tell where they are and where they have been. Another primary function of the Pager is to provide a convenient means to navigate through screen/desktop space. Pressing mouse button 1 in any screen or desktop on the Pager changes the user's physical screen to that space. Dragging with mouse button 2 over a window block causes the corresponding window to be repositioned in virtual space, perhaps to a new screen or desktop. Dragging with mouse button 3 over one of the virtual screens on the Pager causes the physical display to smoothly scroll about the virtual screen space. Although it is possible to exploit the virtual spaces without the Pager, through buttons or menu options, I would discourage doing so. The visual feedback provided by the Pager is outstanding, while operating without it forces the user to maintain a mental image of the spaces. It is easy to forget about the spatial layouts and become lost. A related method of navigating about virtual screens, not strictly a part of the Pager, is also worth mentioning. Whenever the pointer is placed at an extreme edge of the monitor, the physical screen is very rapidly scrolled to the next adjacent virtual screen (if there is one) in the direction of the pointer. Edge scrolling does not cross desktop boundaries. A time-out period may be set with the "EdgeResistance" command, which specifies how long the pointer must remain on an edge before scrolling begins. The "EdgeScroll" command specifies how far the screen is scrolled, given as percentages of the screen. In the example, these are specified at lines 60 and 61. The resistance is set to 250 milliseconds, and the screen scrolls horizontally or vertically by 100%; that is, it jumps instantaneously to the next virtual screen. If desired, edge scrolling may be turned off by setting both EdgeScroll values to 0. Edge scrolling is a potential source of problems for an administrator who is responsible for a large user population. Inevitably, some people will love the feature, and others will find it totally annoying. It is easy to inadvertently invoke edge scrolling, and users are often surprised when it first happens to them. However, the Pager provides consistent feedback and just a little experience with edge scrolling can eliminate the confusion. I personally find it immensely useful, because I can rapidly navigate about virtual space with very simple mouse gestures. The salient point is that you should carefully consider your user community before enabling this feature. Alternatively, a compromise solution might be to make it optionally available through a push button or menu item. Button Panels The button panel module helps automate the performance of frequent tasks by providing a panel of push buttons that can initiate an arbitrary command sequence when pressed. Although it is general purpose in nature, one typical usage is to emulate the ubiquitous toolbar common in MS Windows applications. Each button is defined by a label, an optional icon, and a command string. The buttons can be arranged into the panel in any arbitrary NxM grid. As with the Pager, the panel itself usually has a small footprint, and is typically made sticky across all screen spaces. The icons can be either bitmaps, or pixmaps if fvwm has been built with the Xpm library support. Use of color pixmaps generally makes a positive impact on the aesthetic quality of the graphical environment. Particularly, user's accustomed to MS Windows or Macintoshes take this capability for granted, and often think X Window environments lacking colored icons look cheesy. The fvwm distribution comes with a decent starter collection of color icons, and the web pages point toward sources for others if you are not inclined to create your own. Figure 3 shows an example button panel. It is fairly simplistic, containing six buttons to launch several applications and establish remote connections to some machines I routinely use. Lines 21 and 22 show how the panel is dimensioned and placed. You merely fix the number of rows or columns, and then the module lays out the buttons within your constraints. The definitions of the buttons themselves are given in lines 27-32, in which I simply list a label, a bitmap/pixmap, and an action for each button. Here, all of the buttons are of the same dimensions. However, optional parameters can specify that a button occupy NxM cells in the panel, so some buttons can be made more prominent than others. The commented line 34 shows an example of how this might be done. This line also shows another feature; notice that the action field is an invocation of the Pager module. If this line were uncommented in lieu of line 211, the Pager would be incorporated into the button panel, occuping 4 cells of a row. The default configuration file provided with the fvwm distribution utilizes this feature. Normally, the button panel module, fvwmButtons, supports only one panel. If a symbolic link is created to point to that module, in the same directory that holds all of the module binaries (specified by line 8), then separate, independent panels can be established. They are configured in a similar fashion, except that the linkfile's name is substituted in place of the string *FvwmButtons in the configuration file. Miscellaneous Features Quite a number of window properties can be set both globally or on a per-application basis, using the style command. Lines 91-114 show some examples. Coloring, placement, framing, focus policies, icon pixmap, and other properties are controlled with this command. Notice the use of "*" as a wildcard template in matching application names. The "sticky" attribute is of some interest in the virtual world; it allows a window to remain in view regardless of the current position in virtual space. The program xbiff is a perfect candidate for stickiness, as the whole reason for running it is to be informed when new mail arrives that's defeated if xbiff is not visible. Some features of the window framing are also controlled with the style command, such as the presence/absense of a title bar, coloring, etc. fvwm allows the specification of up to 10 buttons that appear in a window's title bar, each of which can perform some arbitrary command. Furthermore, fvwm allows definition of the shape of the graphic inside the buttons. Lines 74-87 show several examples. Pop-up menus that appear when a user clicks in the root window or somewhere on a window frame are a standard feature in window managers, and fvwm is no exception. Lines 146-204 show how it is done. There are also elaborate mechanisms for mapping pointer semantics and defining keyboard shortcuts. Lines 118-142 show examples of both. Power users are likely to appreciate the keyboard accelerator features. Summary fvwm offers plenty of flexibility in shaping the overall X environment, and I find the extensions and flexibility a joy to work with, especially compared to my frustrations with several proprietary window managers. I've observed it to be a solid product, with very good performance. The web site posts a comparison of the memory requirements for several window managers, and if you believe those numbers, fvwm is relatively lean and mean. I have made extensive use of the virtual spaces features, having realized a productivity gain in several projects. I also appreciate fvwm's adherence to good GUI principles by providing plenty of visual feedback and making simple tasks easy to perform. fvwm's portability and source code availability is of some significance, too. In spite of the intentions announced by the COSE consortium a few years back, member companies have been slow on delivering CDE, thus, there is still no commonly shipped windowing environment across UNIX vendors. With fvwm, it is possible to establish an attractive, professional, usable windowing environment across practically every UNIX platform on the market.
About the Author
Rick is a software engineer for SRI International, at their field office in Leavenworth, Kansas. He can be reached at brownrig@cacfs.ks.erg.sri.com.
|