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
Originally, `dynamicLogString` could have a bottom hidden in it and
thereby crash the `logHook`. Under some circumstances (see #801)
this could cause xmonad to get stuck. We now force the result, and
`dynamicLogString` catches the exception and substitutes a
message (currently "_|_"). Use `dynamicLogString'` for the old behavior.
X.L.StateFull's `FocusTracking` and the eponymous `TrackFloating` were
redundant, hence the former was slated for deprecation. However,
the latter and its host module are somewhat poorly named; the layout
modifier has little relation to floats. As such, it's renamed and
rehosted, becoming the eponymous `FocusTracking`.
The redundant offerings in the original modules are redefined in terms
of the new module where possible, and deprecated.
See: #418; comments on #253, #783.
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.
This combinator forces XMonad to *not* set _NET_DESKTOP_VIEWPORT.
This information is picked up by polybar's xworkspaces module and used
to re-group the workspaces by monitor. I (and others) find this super
confusing, but polybar doesn't not seem open to addressing it.
https://github.com/polybar/polybar/issues/2603
Opting in to the old behavior of not managing this property is one way
to work around it instead.
hlint 3.5 is built against libtinfo6 and works on Ubuntu 22.04 without
needing to install libtinfo5.
Fixes: b7afb0c0bc3f ("ci: Pin runner in hlint, nix workflows to ubuntu-20.04")
...by introducing yet another special case. Unsurprisingly, this is
just a bandaid—the logic in this module is just wrong. It
purposefully (not introduced with this change) computes the wrong
positions for certain extreme points such that splitVertically (which
simply goes down the list of stack windows _in order_) still works.
What we should do instead is to either
- keep track of windows that want to change their size and compute a
rectangle for them first, or
- immediately when handling the resize message, compute *all* of the
new sizes immediately (instead of only for the window getting
resized).
The latter would force us to keep track of the size of the current stack
we operate in, but since 'handleMessage' lives in X this should not pose
a big problem. I reckon this is the better approach.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/788
I have no idea what I was thinking when I wrote that code.
While at it, just reused the code for ICCCM title which already
assumes the client may have broken the rules (I think we have
seen a case of `WM_NAME` being `UTF8_STRING`).
Invoking cabal in the project directory with a cabal.project file might
fail on unrelated dependencies missing, see
4f539734be
Doesn't fail in this repo, but let's keep the workflows in sync.
Both are now broken with ubuntu-22.04. Nix:
error: could not set permissions on '/nix/var/nix/profiles/per-user' to 755: Operation not permitted
hlint:
/opt/hostedtoolcache/hlint/3.4.1/x64/hlint: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory
Breaks `apt update` on the ubuntu-22.04 runner, which is what
ubuntu-latest resolves to these days.
Fixes: 7312d6f3f3f7 ("ci: Drop GHC installation via apt")
When XMonad was recently restarted, it can happen that the workspace
history is empty, hence the last focused window could actually be the
currently focused one. In that case, we don't want to go through the
machinery of looking to hide any NSPs, as there is only one window in
the current workspace (the focused one). This may or may not be a
scratchpad, we don't care.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/779
Starting with time-1.10, the iso8601DateFormat function was deprecated
in favour of more sophisticated methods for showing ISO 8601 date
formats—as such, follow the libraries lead.
Sadly, the new functionality was only introduced in time-1.9, meaning
GHC 8.8 and up. Since we still support 8.6, the introduction of some
CPP is necessary.
