Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
|
|

Development

FVWM 2.6: A new release for a venerable window manager

April 20, 2011

This article was contributed by Joe 'Zonker' Brockmeier.

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.

[Default theme]

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:

This allows for checking of state for commands in a function. The big impact is with testing the state of FVWM when it starts up or restarts. I've covered this a lot in the past -- which goes in to more detail about how FVWM starts up and in part why the Test conditional command is so useful. This allows you to test the state of FVWM at 'Init', 'Start', 'Restart', etc., from a function.

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.

[Alternate theme]

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.

Comments (12 posted)

Brief items

Quotes of the week

On the other hand, we don't really want to require all our contributors to have perfect English. Some of them are Americans, after all.
-- Matt Mackall

If you document it, some idiot will depend on it.
-- Theo de Raadt

The arbitration process is still ongoing, hampered a bit by a full schedule on all parties' parts. There is a draft solution which is currently being discussed. Interested people can receive a copy of the draft solution, but it is private, confidential and anything but final.

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).

-- Boudewijn Rempt on who gets "KOffice"

Our project has an earned reputation for being rejection-happy curmudgeons. This is something I heard more than once at MySQLConf, including from one student who chose to work on Drizzle instead of PostgreSQL for that reason. I think that we could stand to go out of our way to be helpful to first-time submitters.

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.

-- Josh Berkus

Comments (9 posted)

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.

Full Story (comments: 17)

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.

Full Story (comments: none)

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.

Full Story (comments: none)

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.

Comments (42 posted)

Newsletters and articles

Development newsletters from the last week

Comments (none posted)

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.""

Comments (87 posted)

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."

Comments (51 posted)

Page editor: Jonathan Corbet
Next page: Announcements>>


Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds