Last year, I spent a few months running wmii - which was fantastic. Since then I've been playing around with Gnome and KDE, which have advantages like konqueror (as a file manager - I prefer FF as a browser), amarok and knetworkmanager. I have been kinda missing the dynamic window management model though - so obviously I wanted to try out xmonad.
I pulled the source from the darcs repo rather than downloading the "stable" tarball, because my experiences playing around with lambdabot had convinced me that the #haskell guys tend to keep their bleeding edge development repos as stable as many packaged binaries from elsewhere (so long as you have the latest dev tools on your system to build with, that is - which I would like to ^_^). Now this is fairly standard boring stuff, but I thought it worth mentioning in passing, because the obvious thing didn't work right away. xmonad (as mentioned in the readme) has some hackage dependancies which you have to satisfy before anything'll build. This is simple enough - you just download the packages mentioned from the URLs listed, and it should all work - but one of them (X-11-1.2) didn't build:
gds@air:~/hackage/X11-1.2$ ls cbits config.mk.in configure configure.ac Graphics include LICENSE Setup.hs X11.buildinfo.in X11.cabal gds@air:~/hackage/X11-1.2$ runhaskell Setup.hs configure Configuring X11-1.2... configure: /usr/bin/ghc-pkg configure: Dependency base-any: using base-2.0 configure: Using install prefix: /usr/local configure: Binaries installed in: /usr/local/bin configure: Libraries installed in: /usr/local/lib/X11-1.2/ghc-6.6 configure: Private binaries installed in: /usr/local/libexec configure: Data files installed in: /usr/local/share/X11-1.2 configure: Using compiler: /usr/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.6 configure: Using package tool: /usr/bin/ghc-pkg configure: Using ar found on system at: /usr/bin/ar configure: No haddock found configure: No pfesetup found configure: Using ranlib found on system at: /usr/bin/ranlib configure: Using runghc found on system at: /usr/bin/runghc configure: No runhugs found configure: No happy found configure: No alex found configure: Using hsc2hs: /usr/bin/hsc2hs configure: No c2hs found configure: No cpphs found configure: No greencard found checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for X... no configure: creating ./config.status config.status: creating config.mk config.status: creating X11.buildinfo config.status: creating include/HsX11Config.h gds@air:~/hackage/X11-1.2$ runhaskell Setup.hs build Setup.hs: Package X11-1.2 can't be built on this system. gds@air:~/hackage/X11-1.2$
A quick google revealed the problem in an IRC log - my system (a default kubuntu feisty install, with a couple of things like GHC added after) didn't have the X11 development headers installed. I had a quick look (using the KDE prettification of the package manager - adept) for anything obviously called "X11-headers" or "X11-devel", but saw nothing. Rather than spend time searching, I decided to just click on a couple of things that looked like they had a lot of development dependancies, and hope that the package manager would install what I wanted while it resolved them. The packages I installed were called "libxmu-headers" and "libxmu-dev". I may have gotten away with just libxmu-headers, but I forgot to run "runhaskell Setup.hs configure" before trying "build", and so blindly got the same error message as before. Anyway, after installing those two packages, doing configure, build and install worked fine - though there were a load of warnings during the build stage. They looked pretty harmless, so I ignored them. I have so far suffered no nasal daemons as a result. There were similar warnings in building the mtu package.
When I ran configure on the "X11-extras" package, I got the warning:
WARNING: Xinerama headers not found. Building without Xinerama support
...so I installed the ubuntu package "libxinerama-dev", and retried. That sorted everything fine :)
Every time I installed anything from hackage during this process, I searched with adept to make sure that there wasn't already an ubuntu package that would likely make my life easier in the long run. Wouldn't it be great if hackage could be accessed as an ubuntu package repo? Or a debian repo, or whatever. I know that there's some froody "haskell layer" that the gentoo guys can put over their package manager to get stuff like this with the interface they usually use, but a debian one would be nice too. In fact, it would be really nice if hackage could present itself to any distro's package management system - if all the interfaces were well defined... I realise that to do this properly just for ubuntu would mean someone trawling through all the packages in hackage and noting down what debian/ubuntu packages they all depend on, and that this isn't likely to happen any time soon - but hey, I'm allowed to dream :)
Anyway - dependancies aside, the build was simple - I had a binary ready to run in ~/bin
Something's changed in the last few months though - I'm now doing most of my work on a laptop, rather than a desktop. This means I need to have easy access to battery information, and I need to be able to quickly and easily connect to any wireless networks that happen to be around. KDE does this wonderfully - and I've also gotten to quite like amarok ;) I'd rather not give up these luxuries...
There are better solutions - one of which I'll come back to in a mo, but the first thing I wanted was something quick that worked, involved xmonad, and let me keep using knetworkmanager, etc.
So, I opened up .bashrc and added:
I was quite surprised to find how well this worked :) On logging in to X, with this new setting, I saw something like this.
So, the KDE systray isn't working - I guess it needs the window manager to pass it the windows it's supposed to manage - and the kicker is being managed like a window rather than being left to its own devices to place itself at the bottom of the screen.
What I wasn't expecting to work, was these things.
But they do! :) See the notification in the top-left? Those work fine - don't get messed about by the WM at all. This means I get friendly warnings before my power dies, and neat little track name notifications when I'm playing music :)
I could ditch KDE altogether fairly quickly, I think. Most of the things I'd miss can be provided by dmenu, and a couple of command line invocations like "date" and "acpi -b" (though I might need to tweak something in the xmonad source to free up the screen real estate that dmenu would claim, but that doesn't look hard). There's even a dmenu ubuntu package, so that's lovely :)
I don't want to do quite that though, because I'm so addicted to knetworkmanager. I think maybe my ideal setup at the moment would be xmonad, dmenu (with a clock, maybe a couple of buttons for frequently used apps and a battery meter on it) plus a systray of some kind, into which I could put knetworkmanager, klipper and amarok. Apparently the little mini-window things that go into systrays are implemented in X as a special kind of window - which is why they're handled as windows by xmonad. Maybe all that's required is to decide exactly what to do with them, and tell xmonad about the mini-window flag? Dons was good enough to talk us all through the data structure behind xmonad in his recent blog entry, and he said that next time he'd tell us about the IO... So perhaps that'll give me all the knowledge I need to hack together an xmonad systray...?