xmobar, dual-head, and avoidStruts
I finally got around to tweaking my xmonad.hs and had to start using avoidStruts but, it doesn't work with xmobar with a Static position. Works fine with the other positions: Top, Bottom, etc, but with Static, xmonad seems to not know it exists. I like a status bar across the top of both screens. I had been using a Static xmobar with the width set appropriately. But now, that doesn't work. :( I could split my status bar information across two instances of xmobar, no big deal, but to get the second instance to display on the second screen, it seems I have to set its position to Static and then it gets ignored again. So, I'm looking for one of these solutions: 1. a way to get xmonad to recognize a Static position xmobar 2. a way to get a second xmobar instance to show on a different screen without using Static or 3. give up and set up some manual gaps (which I guess is still feasible from looking at Byorgey's config). and hints? Thanks A
On Sun, Nov 02, 2008 at 07:56:56PM -0800, Andrew Sackville-West wrote:
I finally got around to tweaking my xmonad.hs and had to start using avoidStruts but, it doesn't work with xmobar with a Static position. Works fine with the other positions: Top, Bottom, etc, but with Static, xmonad seems to not know it exists.
So here is a clue. It appears that the Static position doesn't export it's dimensions. Here is xprop on xmobar run with Top position: andrew@basement:~$ xprop _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 18, 0, 0, 0, 0, 0, 0, 1279, 0, 0 and xprop of xmobar with Static position: andrew@basement:~$ xprop _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 so I guess it's safe to say this is an xmobar problem? A
On Mon, Nov 03, 2008 at 08:13:46AM -0800, Andrew Sackville-West wrote:
On Sun, Nov 02, 2008 at 07:56:56PM -0800, Andrew Sackville-West wrote:
I finally got around to tweaking my xmonad.hs and had to start using avoidStruts but, it doesn't work with xmobar with a Static position. Works fine with the other positions: Top, Bottom, etc, but with Static, xmonad seems to not know it exists.
So here is a clue. It appears that the Static position doesn't export it's dimensions. Here is xprop on xmobar run with Top position:
andrew@basement:~$ xprop _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 18, 0, 0, 0, 0, 0, 0, 1279, 0, 0
and xprop of xmobar with Static position:
andrew@basement:~$ xprop _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
so I guess it's safe to say this is an xmobar problem?
In Xmobar.hs at line 174 is the following: getStrutValues (Rectangle x _ w h) c = case position c of Top -> [0, 0, nh, 0, 0, 0, 0, 0, nx, nw, 0, 0] TopW _ _ -> [0, 0, nh, 0, 0, 0, 0, 0, nx, nw, 0, 0] Bottom -> [0, 0, 0, nh, 0, 0, 0, 0, 0, 0, nx, nw] BottomW _ _ -> [0, 0, 0, nh, 0, 0, 0, 0, 0, 0, nx, nw] _ -> [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] where nh = fi h nx = fi x nw = fi (x + fi w - 1) which makes no allowance for defining strut values for Static. Any reason why not? I made this crude hack (because I don't really understand what's going on: getStrutValues (Rectangle x _ w h) c = case position c of Top -> [0, 0, nh, 0, 0, 0, 0, 0, nx, nw, 0, 0] TopW _ _ -> [0, 0, nh, 0, 0, 0, 0, 0, nx, nw, 0, 0] Bottom -> [0, 0, 0, nh, 0, 0, 0, 0, 0, 0, nx, nw] BottomW _ _ -> [0, 0, 0, nh, 0, 0, 0, 0, 0, 0, nx, nw] Static _ _ _ _ -> [0, 0, nh, 0, 0, 0, 0, 0, nx, nw, 0, 0] _ -> [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] where nh = fi h nx = fi x nw = fi (x + fi w - 1) and this works. With xprop reporting: andrew@basement:~$ xprop _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 18, 0, 0, 0, 0, 0, 0, 2559, 0, 0 and avoidStruts working properly :) (the 2559 is because I force my xmobar to be two screens wide). So I call this a hack because I don't understand what all the coordinates mean in the case statement. I just mimicked the one for Top since that is where I put it anyway. I suspect there needs to be a little math done to a Static position so that it will work in any position. Can anybody provide insight into what those coordinates represent? Then I could possible put together a proper fix. A
On Sun, 2008/11/02 19:56:56 -0800, Andrew Sackville-West wrote:
2. a way to get a second xmobar instance to show on a different screen without using Static
Juraj Hercek wrote a patch to support xmobar on a second screen a while ago. I can’t find the patch itself, but I’ve attached an old version of Xmobar.hs with the patch applied. Things have changed since then, but you might be able to get it up to date. However, I think the second instance would show the same info as the first instance, at the same location. You would have to tell the second xmobar to use a different config. On Mon, 2008/11/03 08:29:00 -0800, Andrew Sackville-West wrote:
So I call this a hack because I don't understand what all the coordinates mean in the case statement. I just mimicked the one for Top since that is where I put it anyway. I suspect there needs to be a little math done to a Static position so that it will work in any position. Can anybody provide insight into what those coordinates represent? Then I could possible put together a proper fix.
From http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html : _NET_WM_STRUT_PARTIAL, left, right, top, bottom, left_start_y, left_end_y, right_start_y, right_end_y, top_start_x, top_end_x, bottom_start_x, bottom_end_x,CARDINAL[12]/32 Top -> [ 0 -- 0 pixels wide on the left. , 0 -- 0 pixels wide on the right. , nh -- nh pixels tall on the top. , 0 -- 0 pixels tall on the bottom. , 0 -- Not on the left. , 0 -- Not on the left. , 0 -- Not on the right. , 0 -- Not on the right. , nx -- Its left side is at nx on the top. , nw -- It is nw pixels wide on the top. , 0 -- Not on the bottom. , 0] -- Not on the bottom. As you mentioned, your fix won’t work in all positions (such as the bottom of the screen). The difficulty is how to handle screens that aren’t aligned exactly at their tops and bottoms. For example, screens of two different resolutions, or one screen above another screen, or the second screen to the right and at a vertical offset from the first screen. I would argue that a partial solution that handles the most common cases (yours is a start) would be better than nothing. I also like Juraj’s patch.
On Mon, Nov 03, 2008 at 11:29:02AM -0600, lithis wrote:
On Sun, 2008/11/02 19:56:56 -0800, Andrew Sackville-West wrote:
2. a way to get a second xmobar instance to show on a different screen without using Static
Juraj Hercek wrote a patch to support xmobar on a second screen a while ago. I can’t find the patch itself, but I’ve attached an old version of Xmobar.hs with the patch applied. Things have changed since then, but you might be able to get it up to date.
However, I think the second instance would show the same info as the first instance, at the same location. You would have to tell the second xmobar to use a different config.
main = do xmobar <- spawnPipe "/path/to/xmobar" xmobar2 <- spawn "/path/to/xmobar ~/.xmobarrc2" worked just fine for me in this regard.
On Mon, 2008/11/03 08:29:00 -0800, Andrew Sackville-West wrote:
So I call this a hack because I don't understand what all the coordinates mean in the case statement. I just mimicked the one for Top since that is where I put it anyway. I suspect there needs to be a little math done to a Static position so that it will work in any position. Can anybody provide insight into what those coordinates represent? Then I could possible put together a proper fix.
From http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html : _NET_WM_STRUT_PARTIAL, left, right, top, bottom, left_start_y, left_end_y, right_start_y, right_end_y, top_start_x, top_end_x, bottom_start_x, bottom_end_x,CARDINAL[12]/32
thanks for the link! It's still a little unclear what all these fields mean, but having some names for them will help me sort it out. I'll see if I can put together a proper property for Static over the next few days.
Top -> [ 0 -- 0 pixels wide on the left. , 0 -- 0 pixels wide on the right. , nh -- nh pixels tall on the top. , 0 -- 0 pixels tall on the bottom. , 0 -- Not on the left. , 0 -- Not on the left. , 0 -- Not on the right. , 0 -- Not on the right. , nx -- Its left side is at nx on the top. , nw -- It is nw pixels wide on the top. , 0 -- Not on the bottom. , 0] -- Not on the bottom.
As you mentioned, your fix won’t work in all positions (such as the bottom of the screen).
It should be fairly straightforward to convert the xpos, ypos, width and height into useful properties to export for any combination of these four items.
The difficulty is how to handle screens that aren’t aligned exactly at their tops and bottoms. For example, screens of two different resolutions, or one screen above another screen, or the second screen to the right and at a vertical offset from the first screen.
The same spec you link to claims: Struts MUST be specified in root window coordinates, that is, they are not relative to the edges of any view port or Xinerama monitor. IOW, it's entirely up to the user to figure out how to make it work for their funky combination of screens. All we have to do is make a sensible, deterministic set of assumptions about the Static values and plug them into the property.
I would argue that a partial solution that handles the most common cases (yours is a start) would be better than nothing.
yep.
I also like Juraj’s patch.
This is lower down my list, but I'll see if I can figure it out as well, though for me, getting avoidStruts working on my wide xmobar makes me happy :) A
participants (2)
-
Andrew Sackville-West -
lithis