...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
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.
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
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
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).