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. :-)
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.
In the original code, when a GridSelect is shown, user has to use
keyboard to cancel it (ESC key by default). With this field added,
when it is set to True (the default), mouse click on empty space
can cancel the GridSelect.
This contains a breaking change for readHistory, writeHistory,
historyCompletion, and historyCompletionP to take an XPConfig, so they
are aware of this choice. While the latter two are exported, it seems
unlikely to affect many users.
Technically, contrib still does not build with stack, as it forces
xmonad-0.17.0, while only HEAD builds with newer mtl versions. However,
until our dependencies are at least revbumped, this may be the best we
can do.
Related: https://github.com/xmonad/xmonad-contrib/issues/805
These modules were duplicating a substantial amount of low-level code.
`X.A.CycleWorkspaceByScreen` had already separated most of the
implementation details from the logic with `repeatableAction`; all that
was left was to generalise it a little further, put it in a suitable
place and express the other modules through it.
Libraries like Control.Monad are no longer exported from
Control.Monad.Reader et.al.
Related: https://github.com/xmonad/xmonad/pull/427
xmonad/xmonad#d170e99bc5e97db96be9a02b72149103e8d419af
The links were broken due to:
1. Incorrect quotes (' instead of " for module links and occasionally
vice-versa).
2. Changes in the name of the "target" module not reflected in the
"source" docs.
3. Typos to begin with.
4. Use of `<foo>` in the docs is rendered as just `foo` with a link to
`/foo`.
5. Similarly for `"Foo"` if it starts with a capital letter (and hence
could be a module).
6. Markup inside `@` code blocks still being applied.
e.g. `@M-<arrow-keys>@` is rendered as `M-arrow-keys` with a spurious
hyperlink from arrow-keys to `/arrow-keys`, which is confusing.
Three links from XMonad.Util.Run have been removed outright, since
they're no longer examples of the usage of 'runProcessWithInput'.
WmiiActions has been gone since 2008, while XMonad.Prompt.Directory
and XMonad.Layout.WorkspaceDir haven't been using
'runProcessWithInput' since 2020 and 2012, respectively.
In some cases the `<foo>` were surrounded with @, especially in the
case of key definitions, for consistency. (This wasn't done
everywhere, because it looks ugly in the source.)
MoreManageHelpers has never been in xmonad-contrib. ManageHelpers
seems to fill the expected role.
In the case of the module description for X.H.ManageDebug the quotes
were simply removed because none of the likely options to make the
link work were successful.
Add sideNavigation as a fallback if needed. This should not have any
user-facing behaviour change when not using gaps or spacing, as line
navigation is preferred. However, users who do use spacing or gaps
should now potentially not have to change the default strategy in order
to have a usable module.
Essentially, whenever the tutorial actually has decent material on the
subject matter. The replacement is roughly done as follows:
- logHook → tutorial
- keybindings → tutorial, as this is thoroughly covered
- manageHook → tutorial + X.D.Extending, as the manageHook stuff the
tutorial talks about is a little bit of an afterthought.
- X.D.Extending (on its own) → tutorial + X.D.Extending
- layoutHook → tutorial + X.D.Extending, as the tutorial, while
talking about layouts, doesn't necessarily have a huge focus there.
- mouse bindings → leave this alone, as the tutorial does not at all
talk about them.
This may seem a bit self-indulgent, but both of these features are
either quite new or so old that no one remembers them anymore, so not a
lot of up-to-date content exists for them.
This fixes several issues related to parsing of parent PIDs:
* A process with lines or spaces or parentheses in its process name
would confuse the code in X.A.SpawnOn and possibly lead to a
`Prelude.read: no parse` exception.
* `X.H.WindowSwallowing.isChildOf` looked for the parent PID anywhere in
the output of pstree, so single-digit parent PIDs would be considered
as parents of any process with that digit anywhere in its chain of
parent PIDs. (Note that apps in PID namespaces like in Flatpak often
have single-digit PIDs.)
* `pstree` is no longer required in `$PATH`.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/726
