The first thing I complained about the first time I saw Xmonad was the lack of a status bar. As Xmonad approaches its 0.2 release, it has become clear to me that this absence is in fact a feature, not a bug. Here’s why…
It’s now possible in Xmonad to define gaps on the edges of the screen, over which it will not arrange windows. This immediately and beautifully solves the status bar problem, because now you just run a separate status bar app, filling in whatever gap you’ve defined. If the app sets the “override-redirect” X flag (which anything claiming to be a status bar should), it’ll appear on every desktop and be excluded from Xmonad’s window management.
This is a stroke of genius, and a fine illustration of that principle at the beating heart of Unix, namely that you should write apps which do one thing well, and use them in synergetic combination. xmonad manages windows, but it is not in fact its job to provide a status bar: only the space for one. Factoring the status bar out in this manner gives us choice and orthogonality, both of which are A Good Thing.
For now, I’m going for the easy option: dzen, a minimal text-only status bar (looking a bit like this but at the bottom of the screen). Alternatives exist, for example the KDE kicker, but I haven’t really explored that space yet. In all honesty, I’ll probably just stick with dzen. What I want next: a way to display, on the status bar, info about which workspaces are in use, and which is visible. For this, Xmonad will need to report its current status somehow, perhaps like wmii does with its plan-9 inspired pseudo-filesystem.
Update 2007-06-15: very quickly, I got my wish; xmonad now has configurable logging hooks which can write arbitrary data to stdout every time the internal state changes — pipe that to dzen and hey pesto, problem solved. By default there’s a basic logger which simply writes a list of workspaces which currently have windows on, with the current workspace surrounded by square brackets. Lovely jubbly.