X.H.Rescreen, X.A.PhysicalScreens: Add facilities to avoid (some) workspace reshuffling

[liskin]

Description

The changelog says it all:

• XMonad.Hooks.Rescreen

  • Allow overriding the rescreen operation itself. Additionally, the XMonad.Actions.PhysicalScreens module now provides an alternative implementation of rescreen that avoids reshuffling the workspaces if the number of screens doesn't change and only their locations do (which is especially common if one uses xrandr --setmonitor to split an ultra-wide display in two).

  • Added an optional delay when waiting for events to settle. This may be used to avoid flicker and unnecessary workspace reshuffling if multiple xrandr commands are used to reconfigure the display layout.

Well, almost all. One commit message digs a bit deeper:

X.A.PhysicalScreens: Add rescreen alternative to avoid ws reshuffle

Probably a very niche use-case: I have an ultra-wide display that I split into two using xrandr --setmonitor, and I want the workspaces to stay in place when the split ratio is adjusted.

Furthermore, this fixes workspace reshuffling when a virtual monitor is added for screensharing a portion of the screen (https://news.ycombinator.com/item?id=41837204).

Can't think of a scenario involving just physical screens where this would be useful. Those are mostly added/removed, so if anything, one might wish to preserve the workspace that is currently being showed, but that would require knowing the output name (only available via RandR, not via Xinerama). If someone physically moves their displays around and then invokes xrandr to update the layout, this might very well do the right thing, but I don't think anyone moves their displays around often enough to be annoyed by xmonad reshuffling the workspaces. :-)

Also worth noting that I'm don't like the implementation of rescreenSameLength — I feel there must be a better way, but maybe it's okay actually?

Checklist

• I've read CONTRIBUTING.md

  Worth mentioning that a limited version of this functionality (the part that enables clipscreen but not changing the ultra-wide split ratio) could be added to core — skip the rescreen if the old and new cleared rectangles are exactly the same. This being a niche use-case, I think it's okay to keep core as is.

• I've considered how to best test these changes (property, unit,
  manually, ...) and concluded:

  Used it locally. Also, it can't possibly regress anything as existing
  functionality isn't changed at all.

• I updated the CHANGES.md file

[geekosaur]

FWIW I do have a use case involving only physical screens: I have a monitor that likes to disconnect when powered off or even just going into standby, which permutes all my screens as a side effect that I would prefer to avoid.

[liskin]

FWIW I do have a use case involving only physical screens: I have a monitor that likes to disconnect when powered off or even just going into standby, which permutes all my screens as a side effect that I would prefer to avoid.

Hm, but that use-case won't be solved by this PR unfortunately. We'd need to remember something using ExtensibleState to fix that (like: what screen was the current workspace displayed on, and also the visible/screenid mapping). It gets a bit complicated, however — if you change workspaces while the external displays are disconnected, it's not obvious what exactly should be restored.

(I actually have a workaround in place for a similar problem as yours — I disable DPMS whenever any external monitor is connected. I've had it in place for years, the original motivation being GPU hangs and/or kernel panics when the display went to sleep and disconnected. It probably doesn't happen any more, so I could drop it maybe. And then I have another workaround ­— don't respond to xrandr events when the screen is locked.)

[slotThe]

LGTM