Previously, it was necessary to use `borderEventHook` to make sure the
`alwaysHidden`/`neverHidden` lists are garbage collected when a window
is destroyed, but this was largely undocumented. Since xmonad v0.17.0,
the DestroyWindowEvent is broadcast to layouts, so we can just use that
instead and deprecate the event hook.
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. :-)
This handles errors in hooks set using `rescreenHook` as well, not just
those set using the individual adders/setters.
Fixes: 2e3254a9080c ("X.H.Rescreen: Catch exceptions in user-provided hooks in add*Hook")
The primary motivation is to fix `rescreen` messing up the
workspaces/screens order when making small changes to the layout of
multiple screens — such as resizing virtual monitors via `xrandr
--setmonitor`.
cabal 3.12+ is stricter in its checks. Our test suite doesn't depend on
xmonad-contrib (it compiles the modules itself with possibly different
preprocessor defines), thus it doesn't inherit its base bounds.
See https://github.com/haskell/cabal/issues/10162
We only test with GHC 8.6+ and the bounds should reflect that.
Related: 5d0013ef534d ("ci: Drop support for GHC 8.4")
Related: 046f3c3871a7 ("Bump lower bound for base")
Previous version most of the time just got "stuck" on floating windows,
switching back and forth between floating window and tiled window underneath.
This was because "magic point" was left in the same position and thus next
navigation commands selected the same windows over and over again.
Now the "magic point" is moved around such that it doesn't overlap with the previously selected window,
and there are more complicated rules to make navigation between floating and tiled windows more natural.
The original behavior of navigating between tiled windows is preserved almost precisely.
Previous version also prevented switching windows using focusUp/focusDown
when in Full layout. Now there's a special case that handles such situations.
