Restarting xmonad re-runs dzen/xmobar, which puts it at the top of the window stack

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run a status bar (I use dzen) from xmonad.
2. Open a window, and restart xmonad
3. Hide the gap

What is the expected output? What do you see instead?
The window should cover the status bar, but since xmonad ran it after
running the window, the status bar covers the window.

What version of the product are you using? On what operating system?
Latest darcs, Ubuntu.

Please provide any additional information below.
Don Stewart has reproduced this on OpenBSD.

If this error is due to a module from XMonadContrib, please tag this issue
with 'Component-Contrib' below.

Original issue reported on code.google.com by shac...@gmail.com on 18 Nov 2007 at 9:49

[GoogleCodeExporter]

A workaround, with dzen, is to run it with -e 'onstart=lower' -- this lowers 
the dzen
window, so that other windows can cover it.

Original comment by shac...@gmail.com on 16 Dec 2007 at 2:30

[GoogleCodeExporter]

now, xmonad does not run anything and so it is not xmonad that is starting 
another
instance of xmobar or dzen.. so probably you are experiencing some issues with 
you
Xsession startup script. Is this related to documentation you read - that
documentation could be indeed bugged?

For xmobar, you can use the standard input reader: when xmonad quits xmobar is 
going
to quit too. Have a look at XMonad.Config.Sjanssen (of the xmonad-contrib 
library)
for a working example.

I would suggest to mark this report as invalid.

Thanks
Andrea

Original comment by andrea.rossato@gmail.com on 18 Dec 2007 at 10:33

[GoogleCodeExporter]

since nothing has been reported about wrong documentation I'm marking this 
report as
invalid.

andrea

Original comment by andrea.rossato@gmail.com on 24 Dec 2007 at 5:16

• Changed state: Invalid

[GoogleCodeExporter]

We advertise 'spawnPipe' for use with status bars.  This means that the status 
bar is
re-launched every time xmonad is restarted.  The status bar will be higher than
existing windows in the stacking order, so the bar will appear over those 
windows
when the status gaps are turned off.

There's a workaround for dzen, but it's not very obvious.  I'm leving this bug 
open
until we can at least recommend some workaround for xmobar.

Original comment by SpencerJ...@gmail.com on 24 Dec 2007 at 5:26

• Changed state: Accepted

[GoogleCodeExporter]

Workarounds:

Open a new window in the master pane. (Moving an existing window to the master 
pane 
does not work, nor does creating a new non-master window.)

Float a window. (Unfloating does not fix the z-order, though.)

Use the tabbed layout. (If tabbed is in your list of layouts, simply switching 
to it 
will fix the z-order, then you can switch back to your desired layout.)

Original comment by lit...@hethrael.org on 31 Mar 2008 at 10:05

[GoogleCodeExporter]

Status bars should lower themselves on startup, not an xmonad bug.

Original comment by SpencerJ...@gmail.com on 8 Jul 2008 at 8:26

• Changed state: WontFix

[GoogleCodeExporter]

I disagree that status bars should lower themselves on startup, things like the 
gnome
panel actually expect the window manager to keep them at the very top, for 
things
like autohide to work properly.

On the other hand, the fix I've been working on for bug 168 will fix this 
anyway, if
I ever figure out how exactly it should work, since it would unmap struts when 
one
wished not to see them.

Original comment by justin%j...@gtempaccount.com on 8 Jul 2008 at 8:38