avoidStruts uses getWindowInfo dpy rootWindow instead of getCleanedScreenInfo

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Place a dock on a border between screens

What is the expected output? What do you see instead?
  The dock's space is not accounted for, because the strut is set at the maxim extent over all screens in the relevant direction.

The size of the root window is the bounding rectangle of all screens, not the 
size of the screen the dock is on.  This means that if we try to make space for 
a dock that lives "between" two screens, it will actually be allocated on the 
last screen in that direction.

Original issue reported on code.google.com by allber...@gmail.com on 24 Jan 2013 at 3:38

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

...and it occurs to me that we can't represent docks on multiple screens 
properly anyway, since any in the direction of monitor stacking can only be on 
the ends anyway. (I'm poking at our incorrect _NET_WORKAREA implementation.) I 
don't think this can be fixed properly. In particular, since EWMH assumes the 
workspace lives across all monitors, *it* (via strut and _NET_WORKAREA) does 
not support docks between screens properly.

We could still do better than we currently are, but it's going to be a major 
pain.

Also: it has been claimed that the current screen info is from the first Xlib 
check and not updated by monitor changes. The workaround of using the current 
bounds of the root window is flat-out wrong, because we *need* to know the 
boundaries between monitors; some other solution should be found.

Original comment by allber...@gmail.com on 6 Aug 2015 at 8:52

• Changed title: avoidStruts uses getWindowInfo dpy rootWindow instead of getCleanedScreenInfo

[GoogleCodeExporter]

Ok, the Xlib not updating is apparently an xmonad bug. If and only if we have 
Xinerama support (this may mean patches needed to X11 binding), we must receive 
XRRScreenChangeNotify events and make an XRRUpdateConfiguration call in 
response to update Xlib with the new information.

Original comment by allber...@gmail.com on 6 Aug 2015 at 9:24

[GoogleCodeExporter]

And it turns out that the XRandR binding in X11 has everything *except* the 
flag value needed to request XRRScreenChangeNotify events. Oh, and no way to 
conditionally compile or use it; it has a flag compiledWithRandr which is 
either present (and always True) or will fail to link. wat

Original comment by allber...@gmail.com on 11 Aug 2015 at 2:54

[GoogleCodeExporter]

I have made a note about the compiledWithRandr thing at 
https://github.com/haskell-pkg-janitors/X11/issues/32 and will try to find time 
to take a look this weekend. Patches to add XRRScreenChangeNotify events 
welcome.

Original comment by daniel.w...@gmail.com on 11 Aug 2015 at 6:49

[GoogleCodeExporter]

The only thing missing there is the definition of rrScreenChangeNotifyMask; 
everything else needed to add this support to xmonad is there (and already 
written in my local repo, ready to commit and format-patch).

Original comment by allber...@gmail.com on 11 Aug 2015 at 6:53