The testing repo was not a good location for them, and is now
deprecated. They are now in `scripts/build`, and will be documented
in the main repo's `INSTALL.md`.
`ManageDebug` was continuing to report in the `logHook` even after
the `manageHook` was done. In diagnosing this, I discovered that
the original code was using a tuple of `Bool`s and not even a
comment about which meant what.
The code now uses a proper pair type, and dedicated `data`s for
the two flags that make it clear what each means. This also fixed
the bug, so apparently I had the `Bool`s confused somewhere.
I also took the chance to clarify the documentation a little (a
misleading "persistent", since it doesn't use persistent XS) and
a few more cleanups. Also, it now logs all `manageHook` runs
before the `logHook` in case multiple windows are opened.
+ Prefer GHC 8.10.7 to 8.10.4, as versions seem to have stabilised now.
+ Add support for Stackage LTS 19, which ships with GHC 9.0.2.
+ Since a new version of 9.2 has been released, prefer 9.2.2 over 9.2.1.
Also, explicitly pass -XCPP to hlint; see [1].
[1]: https://github.com/ndmitchell/hlint/issues/1360
Since users should not use these functions, anyways, separating them out
seems like a good idea. Plus, one now does not need to scroll over them
to get to the dynamic scratchpad functionality (people may stop when
seeing "DEPRECATED" signs everywhere).
With the extensible state machinery in place[1], we are now able to
seamlessly integrate dynamic scratchpad functionality into
X.U.NamedScratchpad. This is one step into the direction of having a
single scratchpad implementation that can "do anything".
Related: https://github.com/xmonad/xmonad-contrib/issues/591
Related: https://github.com/xmonad/xmonad-contrib/pull/662
[1]: 70d08b82f43057447e8e2479aa515b6db0d199e4
(X.U.NamedScratchpad: Use ExtensibleState to store scratchpads)
Instead of using the scratchpads that the user specifies (as this will
realistically just be "all of them"), create some extensible state for
the scratchpads to reside in.
To ensure that this is done in a backwards compatible way, function
signatures did not change and they instead just ignore the list of
scratchpads given to them and the initialisation is done in the
manageHook, which users already have to use anyways.
We do not ship the nix flake in the release tarball, so it does not make
sense to include NIX.md in there either; at least for now.
Fixes: 4ca46c2414 (Add NIX.md)
There are multiple ways one could use XMonad with nix, so a separate
file for documenting all of this seems appropriate. E.g., when it
contains the respective installation instructions (e.g, "normally" as
instructed in the NixOS wiki, via stack, via flake, ...) we could link
to it from INSTALL.md.
For now it's a good place to document the new `develop.nix`
functionality.
Co-authored-by: Ivan Malison <IvanMalison@gmail.com>
In a multi-head setup, it might be useful to have screen information of the
visible workspaces combined with the workspace name, for example in a status
bar. This module provides utility functions to do just that.
`WindowScreen` is a type synonym for the specialized `Screen` type, that
results from the `WindowSet` definition in XMonad.Core. Having this type
defined and exported in a central module saves extension developers from
trying to reconstruct it, whenever the general `Screen i l a sid sd` is
not suitable.
Note: this should be moved to `XMonad.Core` in the next core release.
X.H.ManageDocks: Avoid unnecessary refresh (loop) for decorations
This started as an investigation of the root cause of
<https://github.com/xmonad/xmonad-contrib/issues/565>, which was
addressed by <https://github.com/xmonad/xmonad-contrib/pull/621> without
having a full understanding of why xmonad ends up in a busy loop.
What was going on:
* X.L.SubLayouts group update algorithm assumes no duplicities in the
Stack, and results in multiplying those duplicities otherwise. Note
that this is a reasonable assumption—duplicities in a Stack have no
defined behaviour in xmonad (X11 can't place a window on a screen
twice), so "fixing" this algorithm is a waste of time.
* X.L.Decoration creates windows which X.H.ManageDocks treats as
possible docks, resulting in extra refresh whenever they appear.
* The extra refresh causes X.L.SubLayouts to multiply the duplicities,
X.L.Decoration to create new decoration windows, and these invalidate
the X.H.ManageDocks strut cache, leading to yet another refresh, and
an endless loop of these.
Having concluded that the no-duplicities assumption is a reasonable one,
there's nothing really to fix here after
<https://github.com/xmonad/xmonad-contrib/pull/621>. Still, the extra
refresh might be causing extra flicker in decorated layouts, and we can
easily avoid it, so I do that here. Plus a bit of documentation for
X.L.SubLayouts.
This started as an investigation/fix of xmonad freezing when a bug in
X.A.DynamicWorkspaces caused duplicate Windows in a single Workspace
Stack, but I soon(-ish) realized that trying to make SubLayouts robust
enough to handle duplicities in a Stack is futile. Any code that creates
duplicities in a Stack is buggy, and must be fixed; the rest can assume
there aren't any.
Instead, let's just document that this is a pre-condition, and that (and
how) stuff will misbehave.
Related: https://github.com/xmonad/xmonad-contrib/issues/565
Windows created by X.U.XUtils.createNewWindow have _NET_WM_WINDOW_TYPE =
_NET_WM_WINDOW_TYPE_DESKTOP, which caused checkDock to match them and an
UpdateDocks event to be sent, causing an additional layout refresh
whenever a decoration window appeared.
This could in theory lead to a refresh loop with a layout (modifier)
that dropped and recreated its decoration windows on every
runLayout—which isn't entirely unreasonable, X.L.MouseResizableTile does
it, just luckily happens to not mark its windows as
_NET_WM_WINDOW_TYPE_DESKTOP.
In practice, such a refresh loop could be triggered when buggy
X.A.DynamicWorkspaces (before 929a6a3f6f) duplicated a Window in a
single workspace's Stack, and buggy X.L.SubLayouts then kept duplicating
the duplication (2 → 4 → 8 → …), triggering the creation of new
decoration window in each iteration.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/565
Adds property tests in both directions for the parser in X.U.EZConfig.
As with the tests for X.P.OrgMode, these (modulo `Maybe` noise) take the
shape of the operation of an inverse semigroup:
pp ∘ p ∘ pp ≡ pp and p ∘ pp ∘ p = p,
where pp is pretty-printing and p is parsing.
The keysymToString function prints the key names in pure ASCII; e.g.,
`keysymToString 250` returns "uacute" instead of "ú". This is
undesirable when printing these keysyms in places like visualSubmap.
Thus, move all of the key infrastructure (heh) from X.U.EZConfig to
X.Prelude and look up the name of the key if possible. For better
composability, slightly change the signature for `regularKeys` and the
associated parser.
