FVWM 2.6: A new release for a venerable window manager

What's a decade between friends? After nearly 10 years of development, the development branch of FVWM (2.5.x) has finally graduated to 2.6.x with the release of 2.6.0 on April 15. The result of 10 years of development is a moderate update that brings FVWM more up-to-date with modern standards for window managers, but does nothing to spoil FVWM for the users who want a very configurable, minimalistic, stable, and lightweight window manager.

FVWM, which stands for F-something Virtual Window Manager, is a window manager derived from the (even more) venerable twm. It got its start in 1993, and has served as the basis for Xfce, Bowman, and a host of other offshoots. The 2.6 release is dedicated to Alex Wallis, known by the nick "awol," in IRC. Wallis founded FVWM's IRC channel (#fvwm on Freenode) and contributed to the FVWM Themes project. Wallis passed away in 2008.

FVWM has likely been skipped over by the most recent waves of Linux converts. It is not shipped as a default desktop by any of the major distributions, and even the distributions that do package it may not offer the best impression of FVWM at first use. The entire FVWM "distribution," weighs in at a mere 2.5MB when distributed as a bzipped tarball. It's licensed under the GPLv2, and is (unlike, say, GNOME) quite simple to compile and install on one's own.

Changes in 2.6.x

Thomas Adam, one of the developers of FVWM, said that it's "difficult" point to major features that will be useful to users in 2.6 "as with any project spanning ten years like this the changes over time compared to an established stable release can be quite large."

The feature list for FVWM is a little different than what one might expect for a more modern window manager. The 2.6.x series brings support for Extended Window Manager Hints (EWMH), mouse gestures, GNU Gettext support for menu items and other "output strings," key/mouse bindings that are specific to windows (rather than the entire desktop), and support for PNG and SVG icons.

The Extended Window Manager Hints allow FVWM to understand "hints" from GNOME and KDE (for example) applications that go beyond the original Inter-Client Communication Conventions Manual (ICCCM) specifications for X client communications. This has long been available in the unstable series or as a module for earlier versions of FVWM. The support for mouse gestures adds the ability to bind mouse gestures to commands in FVWM using libstroke. The release also has a number of new style options to apply to windows and other elements, "not to mention bug fixes and code-refactoring", Adam said.

One thing that users might find useful, in conjunction with utilities like docks or in using FVWM with a desktop environment like GNOME, is EwmhBaseStruts support. This defines "no go" areas of the screen for new windows, so that they won't overlap a dock, button bar, panels, or other items that users might wish to be unobscured. These are all good things for FVWM to have, of course, but many are items that other window managers have already implemented. FVWM doesn't have any "big ticket" new features that would compare with things like GNOME Shell, for example.

Adam also pointed to the Test command that can be used when writing functions for FVWM:

Another change in 2.6.x is a new default path for the FVWM configuration file (now ~/.fvwm/config) and some changes to the format of the config file. Users who are already using FVWM 2.4.x can use the fvwm-convert-2.6 utility that's included with 2.6.x to convert their configuration to the 2.6 style.

Using FVWM

After spending a bit of time with FVWM, it was quickly apparent how much is taken for granted when using mainstream desktop environments like KDE, GNOME, or Xfce as configured and shipped by a major distribution. Little niceties like a system tray or a run dialog that responds when pressing Alt-F2 are just assumed if one is running, say, GNOME. A utility to switch backgrounds and themes is expected in KDE. With FVWM, you'll quickly find how much work has been done for you by the desktop project and/or distribution — and find that have a fair amount of configuration work to do to set up a functional desktop.

That comparison may not be entirely fair to FVWM — a window manager isn't expected to have all the functionality of a full-fledged desktop environment. However, users who've been introduced to the Linux desktop via GNOME or KDE are likely to experience some culture shock.

Aside from a few brief tests, the last time I used FVWM was with FVWM-95 (which attempted to make FVWM look like, you guessed it, Windows 95) on Slackware in 1999 and early 2000. As with Slackware the changes to FVWM are much more subtle than with its counterparts.

I spent several hours reading FVWM's Documentation, man pages, and so on while tweaking FVWM and finding a workable configuration. It quickly became apparent that a few hours would only scratch the surface, at best. FVWM is a long-term project for anyone who hopes to really explore its functionality. The documentation provided by FVWM is very complete, but also a bit scattered. Prepare to hone your Google-fu if you decide to embrace FVWM. One interesting resource is the Config-from-Scratch thread in the FVWM forums.

That's not to say that it's impossible to get started quickly with FVWM, though. FVWM does ship with a couple of sample configurations that can help a user get started. Users can also turn to the FVWM Themes project, or projects like FVWM-Crystal to quickly tame FVWM and make it more attractive than the default.

I installed the FVWM Themes and extras, which were enough to get started with. The themes ranged from clones of Afterbox, BlackBox, Windows XP, and CDE to themes that were (or appear to be) completely original to FVWM. It's possible to hammer FVWM into almost any shape and behavior that you'll find in other window managers or desktop environments.

For the most part, using FVWM was fairly pleasant, though I noticed a few things that would bear fixing or tweaking. When using Chrome and FVWM, for example, FVWM appends an additional title bar and decoration to Chrome. The default themes that come with FVWM Themes include configurations with rather outdated applications. So, for example, the FvwmButtons-Bar configuration includes links to long-defunct or deprecated applications like Netscape and xv.

In short, FVWM is very capable — but a bit cranky and creaky when it comes to trying to wrangle it into something that one can use comfortably. One might even say that it's hard to use — that includes Adam, who admits that FVWM can be hard to use and that it may cause new users to bolt if they are presented with FVWM's default configuration. "It's the one recurring theme amongst new users which is a shame, because as has been proven [...] FVWM can look pretty; it's just at the moment it takes a while to do, and it's this issue I want to try and solve overall." But he said he isn't looking to fix that at the expense of functionality. "I cannot -- no, scratch that -- will not, remove the power and flexibility that FVWM offers the end-user with all these options, regardless of their complexity or sheer volume."

The future of FVWM

That said, Adam would like to better document the options that most users will want to use, and "hope that anything else above and beyond that are specialist cases."

Now that 2.6.1 is out the door, what else is next for FVWM? Adam said that the project has a "bunch of stuff planned", for future releases. He'd like to change the default config for FVWM to "to not look like something from 1995". He also wants to add transparency and composite support, and is thinking of switching to XCB from Xlib, and improving FVWM's module interface.

Adam also said that several of the modules shipped with FVWM will be deprecated in coming releases, including FvwmSave, FvwmSaveDesk, FvwmWinList, and FvwmWharf.

In addition to changes in FVWM, Adam is also planning some changes in the tools that are used for the project. Specifically, Adam said that he wants to move from CVS to git for version control, and away from DocBook to AsciiDoc.

The development cycle will be changing as well, away from the stable/unstable release model that has been in use while FVWM ambled towards 2.6 to stable-only releases with preview releases for testing. "With incremental updates to FVWM, we should avoid lengthy delays/development cycles", he said.

The more the merrier, of course. Adam said that the project is always looking for new people, and not only developers. He'd like to find someone to help with a new default config that is modern, minimalist, but functional — without depending on external tools or applications that do not come with FVWM itself. In response to the state of the FVWM web site, Adam said that he would entertain ideas about revamping the site, but that he wasn't looking to change the site simply for the sake of change.

FVWM is very much an acquired taste. It's extremely powerful in the hands of a knowledgeable and patient user, but likely to be frustrating for anyone who chafes at having to plunge into a text config and documentation to manage their desktop. This release probably won't win over masses of new users, but it will almost certainly please the FVWM community and perhaps lure in a new generation of FVWM users who might have overlooked it before.