Brandon Allbery wrote:

, startupHook = do args <- getArgs guard (null args) $ spawn "xmobar"

Can you point me to some documentation or examples for this? I have found hundreds which follow the pattern main = do xmobarPipe <- spawnPipe "xmobar" xmonad myConfig { ... , logHook = ... xmobarPipe ... } but I don't recall seeing your suggestion before, and yet your suggestion smells much better.

Brandon Allbery wrote:

If you're using a pipe

Yup.

and writing to it in the logHook,

Yup.

then the child xmobar will close automatically when xmonad restarts.

Err, Nope. At least not here it doesn't: me@mybox:~$ head -n 154 .xmonad/xmonad.hs | tail -n 10 main = do xmobarPipe <- spawnPipe "xmobar" dzenPipe <- spawnPipe "dzen2 -p -x -0" xmonad myConfig { logHook = updatePointer (Relative 1 1) >> (dynamicLogWithPP $ myDzenPP { ppOutput = hPutStrLn dzenPipe }) >> (dynamicLogWithPP $ myXmobPP { ppOutput = hPutStrLn xmobarPipe }) } me@mybox:~$ xmonad --recompile me@mybox:~$ killall xmobar dzen2 me@mybox:~$ ps ax | grep dzen2 | grep -v sh | grep -v grep | wc -l; ps ax | grep xmobar | grep -v sh | grep -v grep | wc -l 0 0 me@mybox:~$ xmonad --restart me@mybox:~$ ps ax | grep dzen2 | grep -v sh | grep -v grep | wc -l; ps ax | grep xmobar | grep -v sh | grep -v grep | wc -l 1 1 me@mybox:~$ xmonad --restart me@mybox:~$ ps ax | grep dzen2 | grep -v sh | grep -v grep | wc -l; ps ax | grep xmobar | grep -v sh | grep -v grep | wc -l 2 2 me@mybox:~$ xmonad --restart me@mybox:~$ ps ax | grep dzen2 | grep -v sh | grep -v grep | wc -l; ps ax | grep xmobar | grep -v sh | grep -v grep | wc -l 3 3

spawnPipe is not the same thing as spawn, it creates a communication channel and that is not useful and may be counterproductive if you aren't communicating with the xmobar.

which is what "ppOutput = hPutStrLn statusbarPipe" should be doing (and I'm pretty sure it works, as the status bars *are* getting data all the time). (What would be the point of having an xmobar, if you (xmonad) aren't communicating with it? (Or, rather than "not communicating" do you mean "communicating with it via stdin rather than a pipe"?))

(In particular, if xmobar isn't reading from the pipe because you didn't include a StdinReader in its config, it will never notice when that pipe gets closed.)

Don't you mean PipeReader, if we started it with spawnPipe? And presumably StdinReader would be used with the startupHook version you suggested? In any case, I had neither StdinReader nor PipeReader in my xmobar config. StdinReader doesn't fix it, and PipeReader is for named pipes, which is not what spawnPipe creates, so I wouldn't know how to configure one for this case. Obviously I'm still missing something. Thanks for all your input, it's making all sorts of things clearer.

Brandon Allbery wrote:

You need to configure a StdinReader and use %StdinReader% in the template

Bingo! I didn't have it in the template. Would you happen to know what the equivalent missing component might be for dzen2? (Those still stay alive after xmonad restarts.) Also, I've still got the problem that the new xmobars don't play nicely with toggle struts.

Actually, if you have DynamicLog configured but no StdinReader in xmobar, I'm a little surprised that xmonad isn't eventually hanging

Depends on exactly how 'eventually'. With the bazillion restarts I've been doing, xmobar probably hasn't had the chance to hang around for too long.

Brandon Allbery wrote:

On Sat, Jan 14, 2012 at 19:49, Jacek Generowicz wrote:

Also, I've still got the problem that the new xmobars don't play nicely with toggle struts.

???

When I log in and xmonad starts up for the first time, toggle struts avoids the xmobar and dzen exactly as expected. After an XMonad restart, the newly spawned xmobars and dzens stay on top of any other windows, so when MXonad is not in avoid struts mode, the status bars cover up the top/bottom of the managed windows. If we hark back to the stage where every XMonad restart spawned a new status bar, but the old ones didn't die, I could manually kill all the new ones, leaving just the very first one, and then toggle struts behaviour was just fine, which shows that the problem was with the newly-spawned ones.

Wirt Wolff wrote:

This sounds like the dzen and xmobar aren't lowering themselves when they restart. I thought that was default in xmobar,

Seems that my config file set it to false for some reason.

but you can explicitly add `lowerOnStart=True' to xmobarrc to tell it to do so.

Strange, doing this makes xmobar not appear at all ! (Which might explain why it was set to false in my config file :-)

With dzen2 IIRC it uses -e 'onstart=lower' to do the same thing.

Here too: dzen does not appear at all with this option set. (Yes, I did try them on a screen with no windows on it.)

There's a full list on:

http://dzen.geekmode.org/dwiki/doku.php?id=dzen:option-e

That's uesful. Thanks.

Wirt Wolff wrote:

In this case perhaps you are running nautilus as a desktop manager,

Not consciously, but it was running. I killed it. Both dzen2 and xmobar now interact with toggle struts as expected. Many thanks.

I think anyone using status bars with xmonad does not use the (nautilus) desktop, [...] They set wallpapers directly on the root window with feh, Nitrogen, or similar programs.

Personally, I can't imagine why someone running XMonad would want to set the wallpaper. The whole point is pretty much to make sure that every pixel is occupied by a useful window. The only time I get to see what is on the root window is for the fraction of a second between creating a new workspace and opening something on it :-) Thank you for your help.