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.
Misconceptions
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).
To-Do
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.
Contributing
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 http://code.haskell.org/~shepheb/xmonad-light
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.
Conclusion
I’m off to add ManageDocks support.
Brain Crater 
With my xmonad Debian package maintainer hat on, I say I support this. I might even drop the default configuration xmonad binary from Debian, and install xmonad-light as “xmonad” – I see no reason not to do that.
Good to see that. It was temting to use xmonad on FreeRunner cell phone, but due to space constraints it would be difficult to keep it together with full ghc.
I think many people will be happy with this. Good work, Braden!
Why not fold this into the xmonad core? Worries about adding too much to the currently very lightweight xmonad?
@Liorithiel:
For the record, my i686 xmonad-light binaries weigh in at 2,996,782 bytes. This will increase as more contrib modules are added, but should remain well under 5MB. A drop in GHC’s puddle, but nontrivial.
@David House:
That is under discussion. One reason not to is that xmonad-light itself depends on parts of xmonad-contrib. Currently just EZConfig, but that will change as xmonad-light adds support for more contrib modules (ManageDocks, more Layouts…).
One of the comments on the reddit thread points out a subtle problem I hadn’t spotted.
The standard xmonad binary, finding no xmonad.hs, runs the default config. Finding a broken config, it pops up an xmessage with the errors and keeps running as it was. This is the Right Thing: falling back to the default config (with possibly wildly different layouts and key bindings, no ManageDocks, etc.) is far more disruptive than failing to load the new configuration but continuing to run.
Care is required, then, when restarting xmonad-light, to distinguish between an extant but broken xmonad.hs (keep running as it was), and an xmonad.hs that can’t be used because GHC is not installed, or the xmonad and xmonad-contrib libraries are not installed. In the latter case, what should it do?
Working on a principle of least disruption to the user, it seems better to stop if an xmonad.hs exists (even if GHC or xmonad isn’t installed), and inform the user so. Fail to restart and let the original instance keep running normally. Cascading to xmonad.conf (or even to the default) could be potentially very disorienting.
Fortunately that makes the problem of distinguishing why loading the xmonad.hs failed moot: If the file exists, xmonad-light either succeeds in loading, or continues running normally.
I love this. I was having an issue with installing xmonad on an ubuntu install. Doesn’t detect all of the files – an issue with haskell version of some sort.
Your light program made it very easy for me. I love xmonad! switching over to #! with xmonad as my only wm.
Any more work on the manageDock feature?