[xmonad] xmobar, dual-head, and avoidStruts

[Andrew Sackville-West]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/xmonad/attachments/20081103/fb4efe1c/attachment.bin