Announcing xmonad-light

August 28, 2008

After further work on PlainConfig, and in the light of the impending 0.8 release, it was decided that PlainConfig really doesn’t belong in xmonad-contrib. No one is going to use PlainConfig from their xmonad.hs, that completely misses the point. Cabal doesn’t provide an easy parallel to having make for ordinary contrib and make plainconfig for a PlainConfig-ready binary.

Considering all this, it would be far simpler to have the PlainConfig functionality as a separate Cabalized project with the binary target, that can be configured using ~/.xmonad/xmonad.conf and doesn’t depend on GHC for configuration.

With that, xmonad-light was born. It bears only some resemblance to the XMonad.Config.PlainConfig module currently in xmonad-contrib. I had modified it heavily in my local repository before splitting it into xmonad-light, and never pushed it due to the 0.8 release freeze.


To be perfectly clear, let me explain a few things xmonad-light is, and is not.

Most importantly, xmonad-light is not a fork of xmonad! It depends on xmonad and xmonad-contrib for building. Rather it is an alternative configuration framework for xmonad, and will be distributed as a binary which has been statically linked to xmonad and xmonad-contrib.

xmonad-light is not a sign that xmonad has crippled its configuration, or has moved away from Haskell configurations. The goal of xmonad-light is not to replace Haskell configurations, but to provide an alternative with a much more gradual learning curve. The xmonad.conf to xmonad.hs compiler (see below) makes the transition to a more powerful config easy. This is almost inevitable given the often-seen ramp-up in users’ desire for customization.

xmonad-light is a standalone binary, that does not depend on GHC, xmonad or xmonad-contrib to run on a user’s machine. It has been statically linked against a version of xmonad and xmonad-contrib, namely whatever version was registered with ghc-pkg when xmonad-light was built.

When xmonad-light is executed, it will look for ~/.xmonad/xmonad.hs. Yes, the Haskell file. If it exists, xmonad-light will try to execute it as xmonad normally does. If this fails (GHC error, GHC doesn’t exist, xmonad not installed/registered, etc.) or the xmonad.hs doesn’t exist, it then looks for ~/.xmonad/xmonad.conf and uses that. If neither file exists, it will run the default xmonad config.

When moving to Haskell configuration files, users will need to install xmonad, xmonad-contrib, and GHC normally, as they do now to install and configure xmonad. It will be possible (due to the sequence described above) to mod+q from xmonad-light to normal xmonad.

Current Features

xmonad-light currently supports everything PlainConfig did, which is to say basic configuration of most of the parts of an xmonad.hs. It’s easier to list the omissions and caveats, which are:

  • Layouts are selected from a predefined list, which currently includes only the standard three.
  • Any key sequence, including submaps, can be bound using EZConfig syntax, but the actions are selected from a list. This list includes all the actions required to reproduce the defaults, and can spawn anything.
  • ManageHook conditions are fully expressive, but the actions are selected only from doIgnore, doFloat and doShift "workspace".
  • No support for logHooks.
  • No support for ManageDocks.

The former three are easily expanded to include more layouts and actions as necessary. The latter two are both on my to-do list before releasing a first version of xmonad-light.

The other notable feature is that the compiler from xmonad.conf to xmonad.hs is complete, and supports all the same features as the main part of xmonad-light. Testing (calling it thorough would be to describe having an umbrella as being prepared for a hurricane) has shown that using the generated xmonad.hs works (ie. ghc accepts it) and that the resulting configuration appears to match the xmonad.conf. This functionality will be accessed with a command-line option to the xmonad-light binary.

Usability and Stability

xmonad-light is usabile in the sense that it works, and one could actually use it to configure xmonad without GHC. It is not usable in the sense that there’s no easy way to get and install it yet. There are no known bugs in the code.

xmonad-light is stable in the sense that the API (the xmonad.conf format) is likely to change only by addition of new features. It is unstable in the sense that code and API changes are coming (see below for features I plan to add imminently and in the longer term).


In roughly descending order of priority:

  • Support for ManageDocks.
  • Support for logHooks (probably just basic dzenPP, xmobarPP).
  • Actually add the --to-haskell command-line option.
  • Release a version guaranteed to work against the 0.8 release of xmonad.
  • Add more layouts, key actions and ManageHook actions as they are desired by users.


This has so far been my baby, but I would welcome input (in the form of comments or code) on the design or implementation. The code is available as a darcs repository:

darcs get

The one part of the code that bothers me is the seemingly large amount of duplication, with often nearly identical functions for the XConfig output and the Haskell code output. However, I can’t see a way to do it more generally.


I’m off to add ManageDocks support.