Norbert Zeh wrote:

Marco Guidetti [2011.11.16 1028 +0100]:

...

Hi all,

I have started using xmonad very recently but so far so good, almost everything works exactly as it should. One of the biggest issue I am dealing with right now is xmobar.

I mean: I use two different xmobar instances in xmonad (one at the top and one at the bottom of the screen): the top one has time/battery/xmonad stuff (as in windows, workspace and layout info), the bottom some weather stuff/cpu and so on. I start them in this way: xmproc <- spawnPipe "xmobar ~/.xmobaruprc" (for the top one, which uses DynamicLog) and spawn "xmobar ~/.xmobarrc" (for the bottom one)

Obviously this leads to having multiple instances of xmobar running each time i press mod4Mask+q to restart xmonad (which happens quite frequently since I am still configuring all the stuff I need and playing around with xmonad to understand it better).

I have seen that in XMonad.Hooks.DynamicLog (xmobar) there is a way to do this (even if I still don't fully comprehend how to use it for the DynamicLog, for example). It's not clear to me how to use for multiple xmobar instances (as in my case).

Can someone point to relevant examples (I have found the doc/wiki page, but I don't get it)?

I ran into the same problem. The way I see it, the problem is that xmonad does not keep track of the processes it spawns. Thus, when restarting, these processes stay around. The reason why I think this does not happen with the xmobar spawned as a pipe to receive xmonad's log output is that the xmobar instance dies the moment the pipe gets closed by xmonad.

The way I work around this (I'm running 4 xmobar instances ;) and some other things in my X11 session) is to wrap the invocation of xmonad into a session script that starts all the things I want. Then restarting xmonad does not trigger rerunning the session script and all is well. The only situation where I'm not happy with this solution is when I reconfigure the xmobar instances themselves because they still won't restart when restarting xmonad. In this case, I kill them and restart them by hand.

Why not just spawn all your xmobar instances whith spawnPipe, and then just not using the pipe? This should properly restart all the instances when restarting xmonad. Or would the pipe be garbage collected too early?

On Wed, Nov 16, 2011 at 10:12, Marco Guidetti wrote:

...

Why not just spawn all your xmobar instances whith spawnPipe, and then just not using the pipe? This should properly restart all the instances when restarting xmonad. Or would the pipe be garbage collected too early?

I did try this way, but it doesn't work. I tried it again after receiving your mail, and... it still doesn't work :) Even if I use spawnPipe and I call it someway... something like myUncleJoe <- spawnPipe "xmobar ~/.xmobardownrc" it still doesn't work: once I hit mod+q the number of instances of running xmobar increases.

It's getting EOF from the closed pipe that triggers xmobar to exit. If xmobar isn't reading from the pipe, it won't notice the EOF. You could still do it, just use a dummy StdinReader and write a single newline down the pipe after opening it. bottomBar <- spawnPipe "xmobar ~/.xmobardownrc" hPutStrLn bottomBar "" (Since it's an empty line, the StdinReader won't take up any actual space.) -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On Wed, Nov 16, 2011 at 10:49, Norbert Zeh wrote:

I suppose the output to the pipe is so the StdinReader does not display "Updating...", right? Would it actually be possible to tell xmobar to run the StdinReader but exclude it from its top-level output template? In that case, it doesn't matter what is sent to the StdinReader - it would never be displayed. What I'm not sure about is whether xmobar would actually run the StdinReader and see the EOF. (I don't think xmobar checks whether a monitor is in the output template before starting the monitor.)

The template drives xmobar's behavior; if you don't list the StdinReader there, it won't be run even with a Run instance defined. (I just verified this.) -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

Marco Guidetti [2011.11.16 1612 +0100]:

I am sure there is a more elegant way to do it, maybe using pidof (it didn't work for me tho) but this works, more or less. You say you use 4 instances of xmobar? Can I put xmobar also in "vertical"? That would be nice ;)

No. I'm running two instances each on two screens. N.

Quoting Marco Guidetti :

I tried this, but the biggest problem (for me) was to be able to distinguish between different instances of xmobar running. I solved it with (in the startup shell script):

xmobardown=`ps ax |grep xmobar|grep -v up|awk '{print $1}'` for proc in ${xmobardown} do kill -9 ${proc} done xmobar ~/.xmobardownrc &

I am sure there is a more elegant way to do it, maybe using pidof (it didn't work for me tho) but this works, more or less. You say you use 4 instances of xmobar? Can I put xmobar also in "vertical"? That would be nice ;)

Seems pretty complicated. Why not kill all the xmobars? xmonad is about to restart them anyway. Stick something like this above your 'spawn "xmobar -blahblah"' in xmonad.hs: spawn "killall xmobar" ~d