Template variables essid, quality, qualitybar do not work for me. Also default template seems to be <rx>|<tx>. Additionally the alias suffix 'wi' does not seem to work, %wlan0% work fine though.

Compiled latest git version with flags: with_xft with_iwlib with_utf8.
Thanks

A simple and yet useful example is when I have multiple partitions on a disk, but I want to monitor the complete disk's throughput.
For example: /dev/sda1 is mounted on / and /dev/sda2 is mounted on /home, I want to monitor the complete throughput of the disk (/dev/sda).

I listen to a lot of streaming radio. For whatever reason, the vast majority of stations only broadcast the title of the current song. To be sneaky, they include the artist in the title like: "Artist - Title". When this is displayed, the empty artist info isn't ignored so there is a strange blank space. Mine currently looks like .
You can see the problem there, given that my config is "<artist> - <title>". There's no way to make the 'static' part of the string depend on the tag info.

Idea: If there is a tag field available, we display some user specified string, presumably containing <tag>. If no tag info is available, nothing is presented.

Another simple issue from the mailing lists:

It would be nice to have fallback text for DynNetwork in the event that no connection is established. Some kind of fixed width control for that would also be nice so as not to mess up alignments when the connection goes down.

ColorCache.hs imports xlib conditionally on the xft flag, but requires that import to compile at all.

My weather in xmobar is coming up as "N/A". After a little digging I noticed that the server seems to have moved some files. This appears to be the URL that the source should be pointing at (although I may be mistaken, I can't read Haskell): http://www.crh.noaa.gov/pub/data/observations/metar/decoded.txt

My coretemp sysfs files have shifted since moving to a 3.0 kernel for some reason. On this 4 core processor:

 ~ $ printf '%s\n' /sys/bus/platform/devices/coretemp.0/temp[[:digit:]]_input
/sys/bus/platform/devices/coretemp.0/temp2_input
/sys/bus/platform/devices/coretemp.0/temp3_input
/sys/bus/platform/devices/coretemp.0/temp4_input
/sys/bus/platform/devices/coretemp.0/temp5_input

I don't know whether this is a kernel bug, but it does cause the static check for the existence of "temp1_input" when calling "checkedDataRetrieval" from CoreTemp.hs to fail and display "CoreTemp: N/A".

lm_sensors is still able to find these files without issue. FWIW, an strace of the sensors command reveals that it's actually looking at the /sys/class/hwmon/hwmon2/device/temp{2..5}_{label,input} files, which are symlinks to a coretemp.0 directory under /sys/bus/drivers. Don't know which is more appropriate.

Is anybody able to reproduce this? Maybe a dynamic check for files matching a pattern might be better since you can still derive the actual core number from the label files?

Hi jao,

The recently-introduced XDG_CONFIG_HOME support does not actually work; despite checking for existence of the relevant config file, ~/.xmobarrc is always read. The following patch fixes this issue:

From 4e3119549e5123fc1f800530487ba5903f38ad40 Mon Sep 17 00:00:00 2001
From: Apollon Oikonomopoulos <[email protected]>
Date: Tue, 29 Oct 2013 16:33:14 +0200
Subject: [PATCH] Really read the XDG config if it exists

Commit 7b0d6bff introduced support for configuration files under
XDG_CONFIG_HOME. However, despite checking for existence of an XDG
configuration file, the code would always try to read ~/.xmobarrc.

---
 src/Main.hs |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/Main.hs b/src/Main.hs
index e90a158..99ab3fa 100644
--- a/src/Main.hs
+++ b/src/Main.hs
@@ -110,7 +110,7 @@ readDefaultConfig = do
   home <- io $ getEnv "HOME"
   let path = home ++ "/.xmobarrc"
   f <- io $ fileExist path
-  if x then readConfig path
+  if x then readConfig xdgconf
        else if f then readConfig path
                  else return (defaultConfig,[])

-- 
1.7.10.4

I have those two lines in my .xmobarrc:

Run Com "date" ["+'%a, %d. %b %Y | %H:%M:%S'"] "mydate" 10

Run Date "%a, %d. %b %Y | %H:%M:%S" "date" 10

The first one shows the time in German ("Do, 06. Okt 2011 | 01:45:40"), the second one in English ("Thu, 06. Oct 2011 | 01:45:40"). How can I get the German time when using the built in function? According to the manual there's no way to do this.

With ghc 7.6.1, the deprecated catch has been removed from Prelude (http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.html)

Hence, the buid error:

cabal install --flags="with_utf8 with_xft with_threaded" --haddock-executables
Resolving dependencies...
Configuring xmobar-0.16...
Building xmobar-0.16...
Preprocessing executable 'xmobar' for xmobar-0.16...
[24 of 43] Compiling Plugins.Monitors.Bright ( src/Plugins/Monitors/Bright.hs, dist/build/xmobar/xmobar-tmp/Plugins/Monitors/Bright.o )

src/Plugins/Monitors/Bright.hs:104:26: Not in scope: `catch'
Failed to install xmobar-0.16
cabal: Error: some packages failed to install:
xmobar-0.16 failed during the building phase. The exception was:
ExitFailure 1

xmobar currently strips out any <action> invocations found in the string passed through either StdinReader or XMonadPropLog, the two main ways to send workspace info from XMonad.

Unfortunately, this setup makes it impossible to implement what's probably the number one use of clickable-area support (judging from dzen-based XMonad configs): clickable workspaces, such that clicking on a workspace in the statusbar switches to it.

So why does xmobar do that? What's the rationale behind 85fdac2 ? Security is one possibility, but practically all usage of these two plugins will involve only a string controlled by the end-user, i.e., the log output of their window manager. Are there other reasons to be stripping actions?

Seems to do this with both MPD and AutoMPD. It only pegs a single core, but that has a big effect on battery life. I guess the solution is to always start MPD and leave it running, but I don't always want a song title displayed up there. Or comment out that part of my .xmobarrc when I'm not listening to music.

xmobar 0.17 builded from master with all flags
ghc 7.6.2

Run DateZone "%a %H:%M" "pl_PL.UTF-8" "Europe/Warsaw" "date" 100

gives

xmobar: Enum.toEnum{Word8}: tag (261) is outside of bounds (0,255)

because %a contains polish character 'ę'.

The same char hard coded in other places (i.e. Battery) gives me no error.

If the lowerOnStart config option is set to False, the _NET_WM_STRUT_PARTIAL property of the xmobar window is set to 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.

Support for multi-line strings would be lovely. I'm trying to split up my long ‘template’ record but I can't figure out a way to do it, if any even exists.

Catching Haskell style multi-lines should be fairly easy with Parsec which is what Xmobar is using (I think… Correct me if I'm wrong.).

I measured the number of wakeups per second with powertop with a minimal template (just cpu and memory every second), which generated around 2 wakeups/s, which is what I expected and I'm glad it's so minimal.

However, when I hide XMobar via the DBus interface, the wakeup count is the same, i.e. it still seems to refresh.

I think it's pointless to refresh the values while XMobar is not visible.

What I was hoping to do was to suspend xmobar refreshing until needed, e.g. raising it only when I want. This could save power on battery.

Ideally, I'd like to suspend refreshing of the values from plugins, yet keep xmobar showing the state of XMonad workspaces, but that might require some internal restructuring.

Version:
xmobar version 0.18, compilled with ghc 7.4.2 without -threading.

I think this is because it is colliding with the shared flag percentages padding. This bug might affect other flags too.

This comes up in places like Battery(P). When using the acstatus field, I was hoping to make the AC On status: "Charging" and the AC Off status: "Batt: ", but the is not parsed and is simply left as . I figured this would be relevant in: src/Plugins/Monitors/Common.hs:304, but I can't see why it would replace the .
I figured that was the point of many templateStringParser but it doesn't seem to textually replace it. Is there a way to make this possible easily?

If I add « Run Volume "default" "Master" [] 10 » to the commands. The parsing fails and the program stop.

Tested with 0.18

(git version) xmobar configures and builds fine, but at install:

~/haskell/src/xmobar $ cabal install
Resolving dependencies...
Configuring xmobar-0.16...
Building xmobar-0.16...
Preprocessing executable 'xmobar' for xmobar-0.16...

src/XUtil.hsc:55:8:
    Could not find module `Graphics.X11.Xrender'
    It is a member of the hidden package `X11-xft-0.3.1'.
    Perhaps you need to add `X11-xft' to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.
cabal: Error: some packages failed to install:
xmobar-0.16 failed during the building phase. The exception was:
ExitFailure 1

As I see it, there is no true reason to why xmobar needs to be a seperate execuitable. But rather a module for XMonad.

For all the configuration, that could be in the XMonad config or in a seperate module in ~/.xmonad/lib/XMonad/Hooks/XMobar.hs which would import XMonad.Hooks.XMobar.Core or something.

It would be much cleaner to not have the extra IO of a seperate execuitable. You took the issue that XMonad doesn't have any panel of any such built in. You made a nice tool. Personally, I've been using dzen2 because you didn't have icon support back when I was building my config.

It would be really nice to see XMobar being a module for XMonad instead of an external execuitable. It's not built in, it's not a module so it can't even be added to xmonad-contrib which would increase the use of the pannel.

Sure, building an execuitable can be nice and used for other window managers; So, instead of just ditching the execuitable, it wouldn't hurt to use it's base to keep an execuitable for those users.

Is there any reason that you haven't made xmobar a module for XMonad? You've got all the features you need and a nice way to extend with the plugins. But no module for XMonad it's self?

I'm guessing the AutoMPD (more likely) or the Weather command is causing it. Probably best to check for errors in network commands and back off update rates if things keep failing.

When using the StdinReader plugin, xmobar immediately fails with:

Thread checker failed
xmobar: user error (Text.Regex.Posix.String died: (ReturnCode 13,"repetition-operator operand invalid"))

The error arises from the question-mark used in the regex:

where actionRegex = mkRegex "<action=([^&gt;])*>(.+?)</action>"

I think this is because ".*?" and ".+?" are PCRE constructs that POSIX does not understand...

Since GHC 7.0.2 release, libmpd v0.5.0 cannot be used anymore (without modifying cabal file). But the git version and then the upcoming release have dropped some parameters.

There is at least one which is blocking compilation of the xmobar git version: sgGet

I wanted this to work with OpenBox, and there were some issues. I may not have done this cleanly, but here's what I did to get things working:

--- xmobar-0.14.orig/src/XUtil.hsc
+++ xmobar-0.14/src/XUtil.hsc
@@ -229,7 +229,7 @@ newWindow dpy scr rw (Rectangle x y w h)
\attributes -> do
set_override_redirect attributes o
createWindow dpy rw x y w h 0 (defaultDepthOfScreen scr)

•                    inputOutput visual attrmask attributes
  

•                    inputOutput visual 0 attributes
  

  -- | A version of nextEvent that does not block in foreign calls.
  nextEvent' :: Display -> XEventPtr -> IO ()
  nextEvent' d p = do

--- xmobar-0.14/src/Xmobar.hs 2013-04-22 19:30:12.000000000 -0400
+++ /tmp/Xmobar.hs 2013-04-22 19:29:57.518106675 -0400
@@ -254,8 +254,10 @@
c1 <- internAtom d "CARDINAL" False
a2 <- internAtom d "_NET_WM_WINDOW_TYPE" False
c2 <- internAtom d "ATOM" False

• v <- internAtom d "_NET_WM_WINDOW_TYPE_DOCK" False
• v <- internAtom d "_NET_WM_WINDOW_TYPE_DOCK" True
  p <- internAtom d "_NET_WM_PID" False
• m1 <- internAtom d "_NET_WM_DESKTOP" False
• m2 <- internAtom d "CARDINAL" False

setTextProperty d w "xmobar" wM_CLASS
setTextProperty d w "xmobar" wM_NAME
@@ -263,6 +265,7 @@
changeProperty32 d w a1 c1 propModeReplace $ map fi $
getStrutValues r (position c) (getRootWindowHeight srs)
changeProperty32 d w a2 c2 propModeReplace [fromIntegral v]

• changeProperty32 d w m1 m2 propModeReplace [0xffffffff]

getProcessID >>= changeProperty32 d w p c1 propModeReplace . return . fromIntegral

I'm not (yet, anyway) a Haskell programmer, so I felt pretty dodgy replacing attrmask with '0' but it wasn't clear to me how to do that more cleanly.

The things I'm fixing:

1. override_redirect makes OpenBox completely ignore the window. As such, windows being maximized obscure xmobar.
2. It sets _NET_WM_WINDOW_TYPE_DOCK, which may be useful in addition to setting the partial strut.
3. It sets the window to apply to all desktops.

I wouldn't be surprised if I've botched something, but on the plus side, this does have the pleasant side effect of giving me an xmobar that works with OpenBox.

I have a problem with xmobar coretemp plugin.
Instead of temperature coretemp plugin shows 'error: Prelude.read: no parse'. Problem is reproducible with default plugin config. With xmobar-0.13 everything is ok.

What is the problem? Can anybody help?

In the meantime, a workaround is to use -M 2.

It would be nice if scripts/xmonadpropwrite.hs were in the package on Hackage. I'm building it in Fedora so those who want to use it instead of the standard way can. Not sure where it gets listed in the .cabal file though.

I'm sorry, it built today.
Nevermind the noise.

I tried install xmobar today (--flags="with_xft with_threaded with_utf8 with_mpd with_inotify") and it fails, due to the dependency on transformers-0.2.2.0 which fails to be build by ghc7.6.1:

Configuring transformers-0.2.2.0...
Building transformers-0.2.2.0...
Preprocessing library transformers-0.2.2.0...
[ 1 of 21] Compiling Data.Functor.Product ( Data/Functor/Product.hs, dist/build/Data/Functor/Product.o )
[ 2 of 21] Compiling Data.Functor.Constant ( Data/Functor/Constant.hs, dist/build/Data/Functor/Constant.o )
[ 3 of 21] Compiling Data.Functor.Compose ( Data/Functor/Compose.hs, dist/build/Data/Functor/Compose.o )
[ 4 of 21] Compiling Data.Functor.Identity ( Data/Functor/Identity.hs, dist/build/Data/Functor/Identity.o )
[ 5 of 21] Compiling Control.Monad.Trans.Class ( Control/Monad/Trans/Class.hs, dist/build/Control/Monad/Trans/Class.o )
[ 6 of 21] Compiling Control.Monad.IO.Class ( Control/Monad/IO/Class.hs, dist/build/Control/Monad/IO/Class.o )
[ 7 of 21] Compiling Control.Monad.Trans.Cont ( Control/Monad/Trans/Cont.hs, dist/build/Control/Monad/Trans/Cont.o )
[ 8 of 21] Compiling Control.Monad.Trans.Error ( Control/Monad/Trans/Error.hs, dist/build/Control/Monad/Trans/Error.o )

Control/Monad/Trans/Error.hs:55:21: Not in scope: `catch'
Failed to install transformers-0.2.2.0
cabal: Error: some packages failed to install:
transformers-0.2.2.0 failed during the building phase. The exception was:
ExitFailure 1

Maybe, this is related to #71, but I wonder why ronin13 was able to build it and I am not. I'm using ghc 7.6.1 on ArchLinux.

It seems that xmobar renders all colored text cropped 1 pixel on the right:

Example statusline

Here's the config used to render the screenshot above:

Config { font = "xft:LiberationMono-9"
       , bgColor = "gray30"
       , fgColor = "gray"
       , position = Top
       , commands = [ Run Weather "EDDS" ["-t","<tempC>°C [<rh>%]","-L","18","-H","25","--normal","orange","--high","orangered","--low","lightblue"] 9000
                    , Run Network "eth0" ["-L","10","-H","500","--low","white","--normal","orange","--high","orangered"] 10
                    , Run MultiCpu ["-t","<total0>% <total1>% <total2>% <total3>%","-L","10","-H","50","--low","white","--normal","orange","--high","orangered"] 10
                    , Run Memory ["-t","<usedratio>%","-L","20","-H","75","--low","white","--normal","orange","--high","orangered"] 10
                    , Run Date "%a %e. %b, %H:%M" "date" 50
                    , Run Kbd [("us(altgr-intl)", "USA"), ("rs(latinyz)", "SRB")]
                    , Run StdinReader
                    ]
       , sepChar = "%"
       , alignSep = "}{"
       , template = "%StdinReader% }{Kbd: <fc=#FFFFFF>%kbd%</fc> | Cpu: %multicpu% | Mem: %memory% | %eth0% | %EDDS%, %date%"
       }

I use the Dina font -- obtainable in PCF format for example from kernel.org -- with urxvt and dmenu. xmobar 0.14 however is unable to display it and just falls back to the default X11 font fixed.

Until recently I was just using the specification xft:Dina:pixelsize=16 as a workaround. But then I disabled bitmap fonts in fontconfig to prevent Firefox from using them in certain rare cases. Obviously using bitmap fonts via xft: no longer works. But why doesn't -*-dina-medium-r-*-*-16-*-*-*-*-*-*-* work in the first place? Dmenu, dzen and urxvt have no problem with the font.

Hi,

This may actually be a system issue but I was hoping you could help me troubleshoot it. I found xmobar pins a single CPU core and memory usage explodes until I run out if I display cputemp with cpu3. I've got 4 cpus (0-3). The command looks like

Run CoreTemp ["-t", "Temp: <core0>C : <core1>C : <core2>C : <core3>C"] 10

For cores 0-2, everything goes fine. For 3 and up, I see the memory/cpu issue. I guess I could understand this for core4 since I only have a quad core CPU, but core3 I don't understand. Any ideas?

I was using xmobar with a command pointing to my script on "~/bin/script".

The commit @281a73f "Run Coms using runInteractiveProcess, not runInteractiveCommand" removed the shell expansion feature.

A quickfix is just to expand it manually (what I did). Any way to combine shell expansion and "runInteractiveProcess" security?

For instance http://placekitten.com/ has "{placekitten}" title, and while my chromium has that site open, the error shows in the xmobar place, where current workspaces and current window name should be.

It would be nice to have possibility to set time zone in which you want get date. I'd like to have 2-3 clocks. One local and other of guys with I working with. Currently I use
Run Com "external date with tz script" []
But it looks ugly.

I just upgraded to fedora 18 and thus from ghc-7.0.4 to ghc-7.4.1. Afterwards xmonad and xmobar wake up the cpu too often.

It turned out that the xmonad issue is a ghc issue, which is fixed in ghc-7.6.2 (or 7.4.2, not quite sure). The workaround to compile xmonad using ghc -threaded xmonad.hs fixes the high number of events for me (from 100 to almost none).

However installing xmobar with cabal install xmobar --ghc-options=-threaded doesn't make a difference - xmobar still produces around 75 wakups/s.

My xmobar config is the following:

Config { font = "-misc-fixed-*-*-*-*-10-*-*-*-*-*-*-*"
       , bgColor = "black"
       , fgColor = "grey"
       , position = TopW L 100
       , lowerOnStart = True
       , commands = [ Run Weather "EDDB" ["-t","<tempC>°C","-L","12","-H","30","--normal","green","--high","red","--low","lightblue"] 36000
                    , Run Battery ["-t", "<left> bat"] 50
                    , Run Cpu ["-t", "<total> cpu", "-L","50","-H","75","--normal","orange","--high","red"] 10
                    , Run Memory ["-t","<usedratio>% mem"] 10
                    , Run Date "%a %-d.%m %k:%M" "date" 50
                    , Run StdinReader
                    ]
       , alignSep = "}{"
       , template = "%StdinReader% }{ %cpu% | %battery% | %memory% | %EDDB% | <fc=#ee9a00>%date%</fc>                    "
      }

Any ideas?

Update: This is also reported in the ArchLinux tracker: https://bugs.archlinux.org/task/33277

On my netbook, "current_now" exists, but a read error occurs when attempting to actually open it. Read attempts should be caught and default to "". Will try to patch tonight if I get a chance.

Hi,

Following this http://code.google.com/p/xmobar/issues/detail?id=76
I have added the initial bits to have simple bitmap icon support into xmobar.

"I have working support now,
https://github.com/victoredwardocallaghan/xmobar

It still needs two things:
1.) Handle errors when the icon file is missing
and
2.) Configurable path in the xmobarrc file..

Please tell me what you think.

Cheers,
Edward."

I am looking for feedback and help cleaning it up to be accepted.

Kind regards,
Edward O'Callaghan.

As discussed on the mailing list, I cannot seem to set a fixed width for the watts display in the BatteryP plugin.

It would be great to be able to set background colors as well as foreground colors for the monitors. It makes it much more noticeable when my battery monitor goes below the low threshold, for example, or temperature goes above the high threshold. Being able to set "red:yellow" instead of just "red" might save a meltdown :)

Using xmobar 0.18, compiled with all additional features, fonts seem to be completely ignored. The default font seems to be the only one that is loaded, regardless of setting a new font either in the configuration file or on the command line with the -f switch. In fact, even supplying a nonexistant font produces the same result: no error message, with the default font being used instead.

This is supported in libmpd with withMPD, but xmobar uses withMPDEx (to support parameters via .xmobarrc). The defaults should either query the environment or (better IMO) just use withMPD and have the environment control the mpd server to contact as most mpd tools do.

In my configuration I have pulse-audio, with alsa-mixer as fronted.
And instead my volume level I got following exception:

error: AlsaException.Cons "snd_mixer_selem_get_playback_dB" "Invlid argument" (Errno 22)

My xmobar config:

Run Volume "pulse"  "Master" ["-t", "Vol: <volume>%"] 1

I get the same exception if I use "default" instead of "pulse". It worked before I've moved on pulse-audio.

I used to start xmonad as:

xmobarCmdT = " xmobar -o"
xmobarCmdB = "xmobar -b"
main = do dinT <- spawnPipe xmobarCmdT
          dinB <- spawnPipe xmobarCmdB
          xmonad $ ewmh $ defaultConfig {

(right before xmonad). And xmobar was seen perfectly (latest working
is xmobar-0.15).

Current git version works only if you run xmobar after xmonad.

In my current setup I can't force xmonad windows have their separate
corners (they are always overriden by newly started windows).

I can't bisect right not as i'm on ghc-7.6.
I think i'll be able to do it this evening.
Looks like 'struts*' patches changed behaviour.

Thanks!

Sorry if this has been discussed before. I'd love to hack on xmobar by adding new plugins that suit my needs, but I'm not particularly excited to have to recompile xmobar from source each time and be sure to integrate it into the core. Sure, there are a variety of programs out there that function this way but even they seem to be moving towards a more straightforward, perhaps modular process.

More than anything I bring this up because I'm somewhat spoiled by the way xmonad works. I simply import the official xmonad packages I need, as well as any community created ones that I want, hook them into xmonad core (using a configuration data type which exposes hooks, etc.) and compile that.

Would it perhaps be possible to adopt a structure similar to xmonad's, where xmobar can be imported as a Haskell package? Then plugins can simply hook into it by registering themselves somehow? I have a feeling that would spur development around xmobar.

If the worry is backwards compatibility, I think that a base xmobar binary, with a default set of configuration options can easily be distributed to those whom are not necessarily inclined to do it the new way, perhaps even with support for the existing configuration style.

Adopting this new process would also allow us to use actual Haskell in our configuration files. I don't know if it's possible to do so in .xmobarrc (for example to define helper functions, etc.). I haven't looked at the source but I imagine xmobar simply reads the configuration file into a certain data type, in which case I don't think it's possible to use actual Haskell.

This is not the same as issue #100 which I think goes further and suggests it should be an xmonad module itself. If I understand correctly, the intended direction of xmobar is to be WM-independent, so I can understand why this probably won't be done. However, I think xmobar would greatly benefit from the kind of structure I suggest above. If this is adopted, perhaps later down the road modules can easily be added to xmobar that would allow seamless integration with xmonad itself, as the OP in #100 would like.

I'm using multiple keyboard layouts ("us, ru" actually) and looks like there is no way to display current layout, which would be handy.

When using with pulseaudio with Volume plugin, if at any point of time, there is no
mixer selected (so no output device), it crashes with

        xmobar ~/.xmobarrc
        xmobar: simple.c:160: snd_mixer_selem_get_id: Assertion `elem' failed.
        zsh: abort (core dumped)  xmobar ~/.xmobarrc

The backtrace looks like
https://gist.github.com/931f70faaf221dc12140

Now, it is normal for that assertion to get triggered but xmobar
doesn't need to crash when one of its plugins crash.

I wanted to start a discussion about what people thought of these two features I miss from xmobar.

• dynamic width: with system tray panels, it would be nice if xmobar could manage to resize itself to make room for these panels.
• multiple lines: I have a load of monitors and my panel is totally full, it would be nice to be able to have two lines of info.
  Feedback would be great: how these could be implemented and what issues could come up.

When I tried to build xmobar from 'master' branch on my system, I have faced with such problem.

Xmobar now depends from mtl-2.0, mtl-2.0.1.0 depends from transformers-0.2. When I install mtl-2.0.1.0 and transformers-0.2.2.0, I get this error during building xmobar from 'master' branch.

[25 of 36] Compiling Plugins.Monitors.CoreCommon ( src/Plugins/Monitors/CoreCommon.hs, dist/build/xmobar/xmobar-tmp/Plugins/Monitors/CoreCommon.o )

src/Plugins/Monitors/CoreCommon.hs:31:9:
    Duplicate instance declarations:
      instance (Monad f, Applicative f) => Applicative (ReaderT r f)
        -- Defined at src/Plugins/Monitors/CoreCommon.hs:31:9-61
      instance (Applicative m) => Applicative (ReaderT r m)
        -- Defined in transformers-0.2.2.0:Control.Monad.Trans.Reader

My ghc version is 6.12.3.