Development
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. " 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.
With incremental updates to FVWM, we should avoid lengthy
delays/development cycles
", he said.
Brief items
Quotes of the week
We had an irc meeting last week during which the proposed solutions were discussed. It is however very difficult, not to say impossible to get agreement from both parties on almost any point (as would be expected).
That doesn't mean that we have to accept patches mangled by using an IDE designed for Java, and which lack test cases. However, we can be nice about it.
FVWM 2.6.0 released
Version 2.6.0 of the venerable FVWM window manager is out. "It's been almost five years since the last stable release of FVWM (2006) and almost ten years since the development version of FVWM (2.5.X) which became this latest stable release was started!" There's a lot of new features; see the announcement (click below) for a list.
GNOME 3.2 functionality proposals sought
The GNOME project is beginning to think about what functionality it wants to add to the platform for the 3.2 release. A page of proposed features is being collected. Note that the project isn't looking for wishlist items; it wants projects with developer's names attached. It is still a good place to see where GNOME may go next.The project has also announced a number of changes to its release team.
Linaro ARM optimized toolchain for Android technical preview
The Linaro project has released a technical preview of its ARM optimized toolchain for Android. "Regardless of Android release cycle from AOSP, Linaro would like to bring the latest and ARM optimizing open source technologies to the common software foundation for software stack, and Linaro toolchain deals with all aspects of system-level tools - the core development toolchain (compiler, assembler, linker, debugger)." More information can be found on the project's web site; there are also some benchmark results available.
Oracle: OpenOffice.org to become a "community-based project"
Oracle has sent out a brief press release describing its plans for OpenOffice.org - sort of. "Given the breadth of interest in free personal productivity applications and the rapid evolution of personal computing technologies, we believe the OpenOffice.org project would be best managed by an organization focused on serving that broad constituency on a non-commercial basis." It sounds like Oracle has given up on OOo as a product and is cutting it loose.
Newsletters and articles
Development newsletters from the last week
- Caml Weekly News (April 19)
- PostgreSQL Weekly News (April 17)
The rationale for Ceylon, Red Hat's new programming language (ars technica)
Red Hat has been working on a new programming language called Ceylon. Ars technica looks at the language and the rationale for its creation. "One of the chief goals behind Ceylon is to create a language that will be easy to learn and easy for existing Java programmers to adopt. King seems to believe that a functional programming language would have difficulty meeting those goals. It also seems like a matter of strong personal preference for King—his slides include a rather trollish dismissal of programming languages that are based on "the lambda calculus used only by theoretical computer scientists.""
Managing source code with Mercurial (developerWorks)
developerWorks has posted an introduction to the Mercurial distributed version control system. "Mercurial's revert, backout, and rollback commands make it easy to return to previous versions of specific files or previous sets of committed changes. Git provides a single built-in revert command with its typical rocket-scientist-only syntax."
Page editor: Jonathan Corbet
Next page:
Announcements>>