• Schedule
• Documentation
• Resources
• Thanks

---

Introduction to Fvwm-2.0.46

by Mark Hays

---

Table of Contents

• Introduction
• Some Fvwm2 Screen Shots
• Overview of the X Startup Process
• Fvwm2 Configuration Overview
• Table: Fvwm2 Manpages
• Tour of an Fvwm2 Configuration File
• X Bitmap and XPM Images
• Compiling fvwm-2.0.46
• Fvwm Resources on the Internet

---

Introduction

Fvwm is a window manager for X windows. Fvwm stands for F(?) Virtual Window Manager. From the fvwm1 manpage:

    The name "FVWM" used to stand for something,
    but I  forgot what.  (Feeble,  famous, foobar?
    It doesn't really matter, this is an acronym
    based society anyway.)

There are a number of reasons why you might want to use fvwm:

Platform independence:	Fvwm is freely available and runs on many *nix platforms (eg, SunOS, Linux, IRIX, OSF1, etc.). Once you compile and install fvwm, you can have the same X11 windowing environment on all the platforms you use.
Configurability:	Fvwm boasts a huge number of configuration possibilities. There are very few things that cannot be changed, in fact.
Button Bar:	Everyone loves the fvwm button bar. Once you start using it, you may never use a root-window menu (the one that pops up when you click on the background) again.

There are a couple of downsides to using fvwm, too:

Bugs:	Fvwm has some long-standing bugs; the most annoying one is that your colormap can get trashed under certain circumstances. Typically, your xterms end up with blick text on a blick background. When this happens, you can't tell what the F(?) you're doing.
Colormaps:	Most workstations can display a maximum of 256 simultaneous colors. Using just a few of the pretty color icons can quickly exhaust this resource, at which point bizarre and annoying things start happening. If you need lots of colors for other applications, you might want to avoid fvwm (or avoid using color icons with fvwm).
Configuration:	A conservative lower bound for the number of possible fvwm configurations is 1.0E+200. The product of the mass of the universe and its lifetime in picoseconds is about 1.0E+110. Needless to say, you are completely on your own with your fvwm configuration. As usual, the manpages are your best friend.

This document will (hopefully) ease the pain of setting yourself up to use fvmw2, specifically fvwm-2.0.46. Fvwm2 is officially in beta test -- if you aren't willing to monkey around with your setup and tolerate a few bugs, fvwm2 may not be for you.

Version 1.24r of fvwm is also available on our departmental systems. I chose to present fvwm2 primarily because its configuration is cleaner and clearer. Also, the the FvwmButtons module (which used to be called GoodStuff) has been greatly improved.

---

Screen Shots

Here is an annotated screen shot of fvwm2:

At the bottom of the screen are a couple of icons -- one is a monochrome X bitmap (for emacs), and the other is a color XPM pixmap (for Netscape). Fvwm2 provides a number of icon managment modules; this screenshot shows the simplest one: icons are simply placed on the root window. One of these icon managers can supposedly work like the Win95 taskbar. I haven't tried it. In the middle of the screen is the root menu. You can have an unlimited number of menus invoked in arbitrary ways. This particular menu is invoked by pressing the LMB (Left Mouse Button) on the root window. Finally, the FvwmButtons module is at the upper left corner of the screen:

This row of buttons can be configured to do most anything. The "xterm" button starts up a new xterm, as you might guess. Similarly, the "xcalc" and "netscape" buttons start up those applications, respectively. The leftmost button starts a logout dialog (simlilar to olvwm's). The button bar can also "swallow" some X programs. For example, the above button bar contains running copies of the xclock and xeyes programs. The button bar can swallow fvwm modules -- like the virtual desktop pager on the right.

---

Overview of the X Startup Process

Before getting into the nitty-gritty of fvwm2 configuration, let's go through the X startup sequence (in particular, the files involved).

• You type "startx". Startx is a shell script that sets some environment variables and then runs xinit.
• Xinit starts up the X server and then runs your X startup script.
• Your X startup script executes several commands. The last thing it does is start up a window manager.

When the window manager terminates, your X startup script also terminates. Xinit notices this, kills the X server, and dies itself. Finally, the startx script terminates and you're back at the shell prompt. Your X startup script may be called .xinitrc, .Xclients, .xsession, or .xSession. I'll assume it's .xinitrc for the rest of this document. The .xinitrc is usually a Bourne shell script, but it be anything in reality. A minimal .xinitrc looks something like:

  #! /bin/sh
  test -f $HOME/.Xdefaults && xrdb -load $HOME/.Xdefaults
  exec fvwm2 -f $HOME/FVWM2/fvwm2rc -s

The first line tells UNIX that .xinitrc is a Bourne shell script (it should be fed to /bin/sh). You can make it a csh or ksh script if you like. The second line says that if $HOME/.Xdefaults exists, run the following xrdb command to load it. The third line starts up the window manager. NOTE: You should always start fvwm with the -s option! What the heck is xrdb? Xrdb stands for "X server Resource DataBase utility". The X resource database specifies default values for various applications. For example, here is the part of my .Xdefaults that pertains to xclock:

  !
  ! defaults for xclock
  !     
  xclock*background: steelblue3 ! clock bg color
  xclock*foreground: snow       ! clock face color
  xclock*geometry:   +0+0       ! noninteractive placement
  xclock*hands:      snow       ! color of hands
  xclock*highlight:  snow       ! color of edges of hands
  xclock*padding:    2          ! 2 pixel padding
  xclock*update:     1          ! show second hand

Typical syntax is Application*Resource: Value. Each application's manpage describes the resources it knows about, as well as the allowed values for each resource. You can probably get by with fiddling around with the .Xdefaults you already have. Some people also have a file named .Xresources -- it typically gets loaded after .Xdefaults via an "xrdb -merge $HOME/.Xresources" command. If you have definitions in both of these files, the ones specified in .Xresources will take precedence because they are loaded last. In other words, if .Xdefaults contains the line "xclock*hands: snow" and .Xresources contains the line "xclock*hands: red", the xclock will come out with red hands. The "xclock*geometry: +0+0" line is important if you're going to swallow the xclock into the button bar. An X window geometry specification usually takes the form widthxheight+ x+y. The width and height are in pixels or characters, depending on the application; x and y are in pixels, where the origin is the upper left corner of the screen. A geometry of "-1-1" will place the window in the lower right corner. In the configuration I will discuss, all new windows are placed interactively. When you start an xterm from the button bar or a menu, your mouse cursor will become a large rectangle. Clicking the LMB will "drop" the new xterm at that location. This also applies to programs to be swallowed into the button bar. If you don't specify a geometry for the xclock (in .Xdefaults or on the command line), you will have to interactively place the xclock window. At this point, the window will be swallowed into the button bar. In general, you should specify a position for all windows to be swallowed, but you should not specify a size. You do not have to use the .Xdefaults file. You can specify many of the options for most X programs on the command line. However, it is tedious to type

  xterm -fg white -bg blick -fn \
      '-b&h-lucidatypewriter-bold-r-*-*-*-120-*'

over and over throughout your configuration file. Also, if you ever decide that you'd like all of your xterms to have a MediumSeaGreen background, you only have to edit one line in .Xdefaults. The last configuration file you will need to goof around with is the config file for your window manager. Olvwm uses $HOME/.openwin-menu, fvwm uses $HOME/.fvwmrc, and fvwm2 uses $HOME/.fvwm2rc. The rest of this document describes the .fvwm2rc file. Finally, a word on colors and fonts: colors can be specified in a number of ways. First, you specify a color by name like "blick", "white", or "steelblue3". The list of known color strings is in the file /usr/lib/X11/rgb.txt (or real close to there, depending on what system you're on). A second way to specify colors is to use the form #rrggbb, where rr, gg, and bb are the red, green, and blue components of the color in hexadecimal. Each component ranges from 0 to 255. For instance, "NavyBlue" is 0 red, 0 green, and 128 blue, so you could specify it as #000080. Depending on the revision of X you're using, there may be other ways to specify colors. The easiest way to find nice looking fonts is to run the xfontsel program. If you run "xfontsel -print", pick a font, click "select" and click "quit", it will print out a long string that specifies a font to use. You can put this string in your .Xdefaults, fvwm startup file, etc. Since this string usually contains "*" characters (which are interpreted by the shell), it may be necessary to enclose the string in quotes if you use it on a program command line. To "test drive" a font in an xterm, you can do something like the following:

  xterm -fg blick -bg white -fn "`xfontsel -print`"

NOTE: those are backquotes inside the double quotes. This command will start a blick-on-white xterm with the font you choose in xfontsel.

---

Fvwm2 Configuration Overview

Unlike many other window managers, fvwm has virtually no built-in behavior. In olvwm, for example, you can configure the menu and change a number of options via the .Xdefaults files, but, for the most part, olvwm does not give you a great deal of control over its behavior. With fvwm2, you must define (in .fvwm2rc) the following:

• Fonts and colors for window titlebars, menus, etc.
• The overall appearance and behavior of generic and specific window classes
• The buttons that appear on the titlebar and their function
• Keyboard and mouse bindings for the root window, window components, and titlebar buttons
• All menus to be used, including common window operations bound to the titlebar buttons
• The behavior of any fvwm2 modules used

Fortunately, you do not have to create all of this from scratch. The best way to get started is to take a configuration file and modify it until you get it to do what you want. Fvwm2 is not monolithic; rather, it is broken up into a number of modules. Modules are external programs launched by fvwm. These programs communicate with fvwm via pipes, but they are not actually part of fvwm. For example, the button bar is the FvwmButtons module, and the virtual desktop is the FvwmPager module. You can make use of any, all, or none of the available modules. You can even write your own fvwm2 modules in C, C++, perl, or python! Here is a list of the standard fvwm2 modules:

Fvwm2 Modules and Manpages

FvwmAudio:	Runs audio player for window manager events. From the manpage: BUGS: It's REALLY noisy when fvwm starts and restarts. It runs an external program for each event processed, so it can really bog your machine down.
FvwmAuto:	Autoraises windows when they get the input focus.
FvwmBacker:	Changes background on different desktops to solid color or via command.
FvwmBanner:	Displays an Fvwm logo in the center of the screen for 3 sec.
FvwmButtons:	The nifty Fvwm button bar
FvwmCascade:	Causes windows to be cascaded (like olvwm).
FvwmCpp:	Runs .fvwm2rc through the C preprocessor. This is not a good idea [1].
FvwmForm:	Fillout-form input module.
FvwmIconBox:	Icon manager window. The icons go to the IconBox window.
FvwmIconMan:	Icon manager (like twm's icon manager). More flexible than FvwmIconBox. Can supposedly mimic the Win95 taskbar.
FvwmIdent:	Displays window properties (like xwininfo).
FvwmM4:	Runs .fvwm2rc through the m4 macro preprocessor. This is not a good idea [2].
FvwmPager:	Fvwm's virtual desktop.
FvwmSave:	Attempt to save the current desktop layout as new.xinitrc. This doesn't work with emacs and netscape, in particular. There are many other caveats.
FvwmSaveDesk:	Attempt to save the current desktop layout as .fvwm2desk. Same caveats as FvwmSave.
FvwmScroll:	Add a scrollbar to any window.
FvwmTalk:	Pops up a window that lets you send commands directly to Fvwm. Useful for testing out configuration ideas. A better interface is available as an FvwmForm, though.
FvwmTile:	Causes windows to be tiled (as opposed to cascaded).
FvwmWinList:	Pops up a list of windows. You can perform various operations on the windows via mouse clicks.

Footnotes:

1. The reason this is not a good idea is that Fvwm uses '#' for comments and cpp uses '#' for directives. Thus, cpp may complain loudly while processing your config file, or it may even die.
2. The reason this is not a good idea is 1) most people don't know m4, and 2) you have to be careful about not accidentally using m4 reserved words.

Here is my personal opinion of the standard modules (so feel free to ignore this list!):

Must-have:	FvwmButtons FvwmPager
WM Prefs:	FvwmAuto FvwmCascade FvwmTile
Optional:	FvwmBacker FvwmIconMan
Utility:	FvwmForm FvwmIdent
Other:	FvwmAudio FvwmBanner FvwmCpp FvwmIconBox FvwmM4 FvwmSave FvwmSaveDesk FvwmScroll FvwmTalk FvwmWinList

The "Other" category includes modules that are buggy, dangerous, not too interesting, or redundant (there's another module that does the same thing better).

---

Tour of an Fvwm2 Configuration File

In this section I'll run through the fvwm2rc I'm currently running:

<< Download Sample Tarfile >>

To unpack the tarfile:

  gzip -dc < fvwm2.tgz | tar xf -
  cd FVWM2
  emacs fvwm2rc         # the one I'm running now
  emacs fvwm2rc.example # a good starting point

The fvwm2rc.example is a practical starting point for customization. It is the same as fvwm2rc, but some of the superfluous (gaudy) stuff has been stripped out (menus on the button bar, etc.).

Here is fvwm2rc: fvwm2rc. This file is in HTML format and cannot be used directly; instead, download and unpack the tarfile.

---

X Bitmap and XPM Images

Fvwm can handle two image formats: X bitmaps and XPM images. Both of these are in ASCII format, so you can edit them with vi/emacs or make use of NetPBM/XV/ImageMagick.

X bitmaps are two-color images (fg/bg) that are in an ASCII format suitable for inclusion into C source code. For example, here is /usr/include/X11/bitmaps/Up:

#define Up_width 30
#define Up_height 30
static char Up_bits[] = {
   0x00, 0x40, 0x00, 0x00, 0x00, 0xe0, 0x00, 0x00, 0x00, 0xf0, 0x01, 0x00,
   0x00, 0xb8, 0x03, 0x00, 0x00, 0x5c, 0x07, 0x00, 0x00, 0xae, 0x0e, 0x00,
   0x00, 0x57, 0x1d, 0x00, 0x80, 0xab, 0x3a, 0x00, 0xc0, 0x5d, 0x77, 0x00,
   0xe0, 0xbe, 0xef, 0x00, 0x70, 0x5f, 0xdf, 0x01, 0xb0, 0xbb, 0xbb, 0x01,
   0xf0, 0x59, 0xf3, 0x01, 0xf0, 0xb8, 0xe3, 0x01, 0x00, 0x58, 0x03, 0x00,
   0x00, 0xb8, 0x03, 0x00, 0x00, 0x58, 0x03, 0x00, 0x00, 0xb8, 0x03, 0x00,
   0x00, 0x58, 0x03, 0x00, 0x00, 0xb8, 0x03, 0x00, 0x00, 0x58, 0x03, 0x00,
   0x00, 0xb8, 0x03, 0x00, 0x00, 0x58, 0x03, 0x00, 0x00, 0xb8, 0x03, 0x00,
   0x00, 0x58, 0x03, 0x00, 0x00, 0xf8, 0x03, 0x00, 0x00, 0xb8, 0x03, 0x00,
   0x00, 0x18, 0x03, 0x00, 0x00, 0x08, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00};

Each bit of Up_bits corresponds to one pixel in the image (well, more or less). The rendered bitmap looks like this: XPM v.3 images are also in an ASCII format suitable for inclusion into C source. Here is dilbert_3d.xpm:

/* XPM */
static char * dilbert_3d_xpm[] = {
"56 36 27 1",
"       c none",
".      c #28A25D754924",
"X      c #FFFFFFFFC71B",
"o      c #FFFFE79DBEFB",
"O      c #E79DE79DEFBE",
"+      c #EFBEF3CEF7DE",
"@      c #FFFFFFFFD75C",
"#      c #B6DAAEBAB6DA",
"$      c #AEBAA699AEBA",
"%      c #71C679E78617",
"&  c #BEFBC30BCF3C",
"*      c #28A22CB230C2",
"=      c #AEBAAEBAB6DA",
"-      c #96589658AEBA",
";      c #FFFFF3CEFFFF",
":      c #514471C68E38",
">   c #AEBAB2CACF3C",
",      c #30C234D330C2",
"<   c #A6999E79A699",
"1      c #BEFBB6DABEFB",
"2      c #79E786179E79",
"3      c #000000001861",
"4      c #C71BBAEAC71B",
"5      c #000000001040",
"6      c #A69979E78E38",
"7      c #BEFB20812081",
"8      c #082004100820",
"                                                        ",
"                                                        ",
"                            .                           ",
"                          ..X.... .                     ",
"                           .oOoo .+. .                  ",
"                           .XoooooX .X...               ",
"                           .oooo@ooooo++X.              ",
"                          .+oooooooooooo#.              ",
"                          .XoooooooooooX.               ",
"                          .ooooooo@ooooO.               ",
"                         .oooooooooooo@.                ",
"                         .Xoo@ooooooooo.                ",
"                        .+$.%Oooooooooo.                ",
"                       ..$.+&....oooooo.                ",
"                      . ..O++*=+-.ooooX.                ",
"                      .*.=++O.+++.oooo.%                ",
"                       ..O+O+.O+O.$++;:.                ",
"                     . :.>O+.%+++.:%..%.                ",
"                      .>o*..O.++,+ooX@:<.               ",
"                      .ooo+ooO..$ooooo1#.               ",
"                      .oo..oo>oooooooo.%                ",
"                      .@%>ooo-.ooooo+:1.                ",
"                     .oo.ooooo.+ooooo..                 ",
"                     .Xo.ooooo*oooooo.                  ",
"                     .oo.-ooo$.oooooo.                  ",
"                    .+ooo..:..oooooo>:                  ",
"                    .ooooo+#+oooo@oo.                   ",
"                   %=ooooooooooooooo.                   ",
"                   .<ooooooooooooooo.                   ",
"                   <.-ooooooooooooo+.                   ",
"                 :.+O..-ooooooooooo.                    ",
"               22;=.>O%33...:%&:4:%..:                  ",
"             %%+++O+..%..53.;;-;+;+O;.                  ",
"            %+++++O.>6+77.8.OO+O+OO+$.+                 ",
"                                                        ",
"                                                        "};

The rendered image looks like this: XPM image data consists of three parts:

• Overall image properties
• Color table
• Image data

The first line of string data gives the overall image properties: this image is 56x36, uses 27 colors, and encodes each pixel as one character. Next comes the color table. It consists of 27 strings. Each string contains a character, the letter "c", and an X color specification (which can be a color name or RGB spec). The color specification "none" means that the corresponding pixels will be transparent. Finally, this image contains 36 strings, each of length 56, of image data. Each character in the image data maps to one of the entries in the color table.You should be aware of an important hardware limitation: many types of video hardware can display a maximum of 256 distinct colors. You can typically choose these 256 colors from of a palette of approximately 16 million colors. Once the available color slots are exhausted, strange things start to happen. For example, XV and Netscape will begin dithering images using the existing color table -- sometimes with visually disturbing results. Xterm and emacs might start to complain about not being able to allocate colors. If this happens to you, there are three ways to go.First, you can use private colormaps with netscape and xv. When the mouse enters the netscape window, the entire colormap will be swapped out in favor of netscape's. The netscape window will look even better than usual, but the rest of the desktop will look goofy. Many people find private colormaps really annoying, however. To see the effect first-hand, run "netscape -install".The second option is to get rid of some of the pretty color icons. Since the window manager is one of the first X applications to start, it gets the first crack at color allocation. By getting rid of some superfluous icons, you leave more available slots for other applications to use.The third option is to perform color reduction on the icons you want to use. Since icons are small, it's usually hard to tell the difference between one that uses 220 colors and the same image reduced to 10 colors. For example, here's Dilbert (27 colors) and Dilbert reduced to 6 colors: This color reduction was achieved using the ImageMagick convert and mogrify commands.

  convert -colorspace YIQ -colors 6 \
      dilbert_3d.gif dilbert_6.gif
  mogrify -transparent '#ffff00000000' \
      dilbert_6.gif

This problem can become serious. After adding icons to the menus on the button bar, I found out that I was using more than 240 colors for 15 icons! Here's how I reduced the whole collection to a total of 32 colors:

• Copied all the icons I wanted to use to a directory.
• Used the ImageMagick "montage" command to create a large GIF image containing all of the icons.
• Used the "mogrify" command to reduce this composite image to 32 colors.
• Used XV's cropping ability to extract each color-reduced subimage to a GIF of the same size as the original icon. This was tedious.
• Used XV to touch up the colormaps on these GIF images as necessary. For example, some of the icons had artifacts near sharp edges. You won't notice the artifacts until you turn on transparency -- the edges will look ragged.
• Some of the images (like the gnu) had interior regions the same color as the background. I loaded these into xpaint and floodfilled the background with red (red was later made transparent). This revealed more artifacts that were touched up by hand.
• Used the "convert" command to convert the small GIFs to XPM format.
• Ran emacs on the XPM files to set transparency by hand. Also, "convert" marked some of the colors as "Transparent", which caused fvwm to choke. Some of these entries were changed to "none", others were changed to a particular color -- based on the original XPM icons.
• Copied the XPM icons into my fvwm directory and altered PixmapPath accordingly. Restarted fvwm and hand-edited the XPMs some more until things looked OK.

All of this took about two hours -- or about 8 minutes per image. That's a lot of work for pretty color icons! But that's life in the big city.

---

Compiling fvwm-2.0.46

If you want to try fvwm-2.0.46 at home or in your office and if it isn't already installed, you will need to obtain the source code and compile it yourself. Fortunately, this is pretty easy to do. The fvwm2 distribution comes with a file named "INSTALL" that gives detailed instructions. Here's the basic procedure:

  gzip -dc < fvwm-2.0.46.tar.gz | tar xf -
  cd fvwm-2.0.46
  <edit Fvwm.tmpl>
  xmkmf
  make Makefiles
  make
  make install install.man
  mkdir /path/for/the/xpm/icons
  cd icons
  tar cf - . | \
      (cd /path/for/the/xpm/icons && tar xf -)

The editing step is described in the INSTALL file -- in particular, you might want to change the installation paths or you might need to specify the link options for the XPM library.Locations of the source code for fvwm2 and the XPM library are given in the next section.

---

Fvwm Resources on the Net

There are a number of fvwm resources availble on the net:

Home Page:	The official fvwm home page is http://www.hpc.uh.edu/fvwm/. It contains pointers to the latest source, documentation, FAQs, and links to other fvwm sites. THIS SITE IS NO LONGER ACTIVE.
XPM Library:	If you want to (re)compile fvwm yourself, you'll also probably want to install the latest XPM library (if you don't already have it) so you can use the nifty color icons. The latest version is available from ftp://koala.inria.fr/pub/xpm/ or ftp://ftp.x.org/
Sample Configs:	The sample fvwm config files available from http://www.public.iastate.edu/~crode/fvwm/ are a good source of configuration ideas. This site includes screen shots. THIS SITE IS NO LONGER ACTIVE.
Hacked fvwm's:	There are at least two hacked versions of fvwm available: Fvwm95-2: Fvwm with a Windows95 look & feel AfterStep: Fvwm with a NextStep look & feel They are described on the fvwm home page. I have tried both of them -- they're pretty cool, but my experience has been that they aren't terribly stable.