AvoidStruts gives wrong window heights with vertically stacked screens

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use two xinerama screens arranged one --above the other (by xrandr),
with avoidstruts as the default layout
2. Place one xmobar at the top of each screen 

What is the expected output? What do you see instead?
Windows on one screen are given heights in excess of the original screen
height. This crashes some applications or makes them very slow.

What version of the product are you using? On what operating system?
contrib built from darcs, as of April 20, 2009 (nothing has changed to that
code since, however).  I don't have an xinerama setup anymore to test this (1)

On Arch Linux

Are you using an xmonad.hs?  Please attach it and the output of "xmonad
--recompile".

xinitrc:

 #!/bin/sh
 xmobar -x 0 &
 xmobar -x 1 &
 exec xmonad

xmonad.hs

 import XMonad
 import XMonad.Hooks.ManageDocks

 main = xmonad defaultConfig { manageHook = manageDocks
                             , layoutHook = avoidStruts $ layoutHook
defaultConfig }

xmobarrc: no xmobarrc, built from darcs to accept the -x flag, but that
could be done with separate config files.

Please provide any additional information below.

Attached is what I investigated and sent to Joachim Breitner (the struts
values which cause the failure), but he referred me to xmonad@

Speculation(2) : The avoidStruts code considers the origin of each screen
to be (0,0), when it is (0,800). Then it applies the struts that refer to
dimensions below the current screen, leading to Word16 underflow. Perhaps
ManageDocks should ignore struts that cover areas outside of the current X
screen, and also subtract off the current screen origin from the struts
that do fall within the screen.

(1) LayoutScreens may be of use here
(2) likely wrong since avoidStruts works correctly with horizontally
arranged screens

Original issue reported on code.google.com by vogt.a...@gmail.com on 28 Sep 2009 at 4:42

Attachments:

• debugging

[GoogleCodeExporter]

This should be tagged contrib.

Original comment by vogt.a...@gmail.com on 28 Sep 2009 at 4:47

[GoogleCodeExporter]

From some discussion in #xmonad, this supposedly has to do with xmobar setting
illegal struts.

The simple workaround currently is to arrange the windows horizontally.

Nevertheless, ManageDocks should not fail as badly as it does (ie. ensure that
running `avoidStruts l' covers less area than `l')

Original comment by vogt.a...@gmail.com on 21 Oct 2009 at 3:55

• Changed state: Accepted
• Added labels: Component-Contrib, Priority-Low, Type-Defect

[GoogleCodeExporter]

http://www.haskell.org/pipermail/xmonad/2009-November/009145.html
This, I believe, fixed the issue and discusses why it changes the strut 
semantics
incompatibly with wm-spec.

Original comment by liskni...@gmail.com on 19 Nov 2009 at 9:38

[GoogleCodeExporter]

After a discussion on IRC with sjanssen I sent a mail to wm-spec-list about this
issue and a cleaner solution was proposed. However, nobody else except me and 
the one
behind the proposal has commented on this, and I suppose it takes weeks to get a
proposal through to wm-spec. If that eventually happens, I'll provide patches 
for
xmonad and xmobar. At that point, this hack might be dropped, but the original
behaviour needs to be fixed, anyhow, so we may as well leave it.

If anyone's interested, this is the relevant thread on wm-spec-list:
http://thread.gmane.org/gmane.comp.gnome.wm-spec/1531/focus=1772

Original comment by liskni...@gmail.com on 27 Nov 2009 at 12:14

[GoogleCodeExporter]

This has been fixed for a while by liskni.si's patch.

Original comment by vogt.a...@gmail.com on 3 Jan 2013 at 6:30

• Changed state: Verified