One status bar process, visible on N screens

Hello, When running unity-2d-panel, the panel appears once on each screen, even though a single process is running. (There is a glitch where the width of the narrower screen determines the width of the panel, so it doesn't span the whole screen width on the wider screen.) At the moment I am spawning two xmobar or dzen2 processes, one for each screen. This isn't really satisfactory: Requiring multiple processes merely to display exactly the same information, and hard-wiring 2 bars, is rather grating. Have you any suggestions on how to configure XMonad so that a single status bar is visible on every visible screen that happens to be connected at any time? Thank you.

On Mon, Jan 16, 2012 at 16:30, Jacek Generowicz
When running unity-2d-panel, the panel appears once on each screen, even though a single process is running. (There is a glitch where the width of the narrower screen determines the width of the panel, so it doesn't span the whole screen width on the wider screen.)
The glitch should alert you to what's really going on: the GNOME panel (Unity is built on top of GNOME) uses a single process for all panel windows, but the windows are actually independent. Unity is simply arranging for the same applet config to be used in each of the windows (it's actually running the applets multiple times). (The way the GNOME panel works, this amounts to duplicating some gconf/dconf keys, so that each panel has its own copy of the config.)
At the moment I am spawning two xmobar or dzen2 processes, one for each screen. This isn't really satisfactory: Requiring multiple processes merely to display exactly the same information, and hard-wiring 2 bars, is rather grating.
But that is all X11 supports; you can't actually display a window in multiple places, you have to create separate windows with independent contents. It's not up to xmonad to control this.
Have you any suggestions on how to configure XMonad so that a single status bar is visible on every visible screen that happens to be connected at any time?
As stated above, this is simply not possible. xmonad doesn't have any control over it; X11 only allows a window to be visible in one place at a time. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

Brandon Allbery wrote:
On Mon, Jan 16, 2012 at 16:30, Jacek Generowicz
wrote: Have you any suggestions on how to configure XMonad so that a single status bar is visible on every visible screen that happens to be connected at any time?
[...] this is simply not possible.
Fair enough. How about getting XMonad to figure out how many screens there are, and to start one on each screen? Maybe even removing/adding them as screens are (dis-)connected? Failing that, how about running a single status bar on the first screen, but being able to toggle struts on that screen even when the focus is on some other screen?

Quoting Jacek Generowicz
How about getting XMonad to figure out how many screens there are, and to start one on each screen? Maybe even removing/adding them as screens are (dis-)connected?
Here is a snippet from my xmonad.hs (with a few complicating factors removed): import XMonad import XMonad.Hooks.DynamicLog import XMonad.Layout.IndependentScreens import XMonad.Util.Run main = do nScreens <- countScreens hs <- mapM (spawnPipe . xmobarCommand) [0 .. nScreens-1] xmonad $ defaultConfig { logHook = mapM_ dynamicLogWithPP $ zipWith pp hs [0..nScreens] } xmobarCommand (S s) = unwords ["xmobar", "-x", show s, "-t", "%date%%StdinReader%"] pp h s = marshallPP s defaultPP { ppOutput = hPutStrLn h } You will probably not need marshallPP if you are not using IndependentScreens. Still, perhaps you will find this starting point useful for your own experimentation. ~d

At Mon, 16 Jan 2012 21:01:52 -0500,
Quoting Jacek Generowicz
: How about getting XMonad to figure out how many screens there are, and to start one on each screen? Maybe even removing/adding them as screens are (dis-)connected?
Here is a snippet from my xmonad.hs (with a few complicating factors removed):
import XMonad import XMonad.Hooks.DynamicLog import XMonad.Layout.IndependentScreens import XMonad.Util.Run
main = do nScreens <- countScreens hs <- mapM (spawnPipe . xmobarCommand) [0 .. nScreens-1] xmonad $ defaultConfig { logHook = mapM_ dynamicLogWithPP $ zipWith pp hs [0..nScreens] }
xmobarCommand (S s) = unwords ["xmobar", "-x", show s, "-t", "%date%%StdinReader%"] pp h s = marshallPP s defaultPP { ppOutput = hPutStrLn h }
That's great as a starting point. Many thanks. Did marshallPP and defaultPP appear in IndependentScreens between xmonad-contrib versions 0.9.2 and 0.10? Is there an easy way of finding the docs for older versions? As for adapting the number of status bars to the current number of screens, with something like the above in place, it's just a question of restarting xmonad when the screen configuration changes, which would be a workable solution. But if anyone has any suggestions on getting XMonad to spot the change itself, I'd be interested. Thank you.

Quoting Jacek Generowicz
Did marshallPP and defaultPP appear in IndependentScreens between xmonad-contrib versions 0.9.2 and 0.10? Is there an easy way of finding the docs for older versions?
marshalPP is new in 0.10. defaultPP is provided by DynamicLog and is not new. Older versions of the documentation are available on Hackage; click the version numbers at the top of this page: http://hackage.haskell.org/package/xmonad-contrib 0.9.2 doesn't seem to be available, but 0.9.1 is and should be quite close to the same.
But if anyone has any suggestions on getting XMonad to spot the change itself, I'd be interested.
Look into the eventHook. I believe clients are sent a message when the number of screens change. Supposedly, xmonad itself has some machinery for spotting this kind of thing, so you may be able to crib some code from core. ~d

At Tue, 17 Jan 2012 11:08:43 -0500,
Quoting Jacek Generowicz
: Is there an easy way of finding the docs for older versions?
0.9.2 doesn't seem to be available, but 0.9.1 is and should be quite close to the same.
Hmm, I saw that 0.9.2 was missing, and assumed the same was true for all older versions. Sigh. Less haste, more speed.
But if anyone has any suggestions on getting XMonad to spot the change itself, I'd be interested.
Look into the eventHook. I believe clients are sent a message when the number of screens change. Supposedly, xmonad itself has some machinery for spotting this kind of thing, so you may be able to crib some code from core.
Thanks for the suggestion. I'll file this for the long-term future. I used your code as inspiration for: main = do nScreens <- countScreens xmobars <- mapM (spawnPipe . xmobarCommand) [0 .. nScreens-1] dzens <- mapM (spawnPipe . dzenCommand) [1 .. nScreens] xmonad myConfig { logHook = updatePointer (Relative 1 1) >> mapM_ (dynamicLogWithPP . (bindPPoutput myDzenPP)) dzens >> mapM_ (dynamicLogWithPP . (bindPPoutput sjanssenPP)) xmobars } xmobarCommand (S n) = "xmobar -x " ++ show n dzenCommand (S n) = "dzen2 -e 'onstart=lower' -xs " ++ show n bindPPoutput pp h = pp { ppOutput = hPutStrLn h } With this, I just have to hit 'Mod-q' after the number of screens changes, to get the right number of status bars. This is such a trivial glitch compared the major configuration issues I have yet to resolve, that I'm perfectly happy with this solution at the moment. Thanks for your help.
participants (3)
-
Brandon Allbery
-
Jacek Generowicz
-
wagnerdm@seas.upenn.edu