[xmonad] Xmobar Plugin Development
blasdelf at gmail.com
Mon Jul 14 17:59:41 EDT 2008
On Mon, Jul 14, 2008 at 1:11 PM, Spencer Janssen
<spencerjanssen at gmail.com> wrote:
> 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
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):
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 :)
More information about the xmonad