On Mon, Jul 14, 2008 at 1:11 PM, Spencer Janssen
First I'd like to point out the author of xmobar, Andrea Rossato, probably doesn't follow this list anymore. If you'd like to see action on these issues, you should probably forward this message to him.
I did, and we've already replied to each other a few times :) I've pointed him here in my last reply.
Andrea has chosen to use Read/Show serialization for xmobar rather than Haskell source ala xmonad. The things you mention are the negative aspects of this choice, but there are positive aspects -- not requiring GHC as a runtime dependency is a major one.
Isn't nearly every xmobar user a xmonad user? I thought that was the impetus for xmobar's existence. It's true that ghc takes up 300mb on disk plus dependencies, but I and most all other users already have it there for xmonad (if not just for haskell development). I find ghc's compilation of my xmonad.hs pretty snappy on my OLPC XO-1, I'll have to test it out on a 70mhz Sparcstation 5 (the slowest hardware I've used that can usefully run Xorg) the next time I'm back at my alma mater (though I may have to wait a few days for ghc to compile!). Interestingly, there's a module in the xmonad-contrib darcs that allows you to avoid the runtime ghc dependency (though you still need ghc to build the initial xmonad.hs, a debian packager could do that and make it global): http://code.haskell.org/XMonadContrib/XMonad/Config/PlainConfig.hs Unfortunately you can't import anything from xmonad-contrib without using ghc to rebuild the xmonad.hs (a debian packager could make the default import all nonconflicting modules when contrib is installed). You also can't currently use any layouts from contrib, but more worrying for xmobar you also can't use a logHook :(
In fact, I've written xmobar plugins but have not distributed them because there isn't really a convenient way to do it.
Please do, publishing is rarely a bad thing :) -- Fred