+ 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.
This changes KeyPress handling in these modules to behave much closer to
how xmonad core itself handles keypresses. The primary difference lies
in that xmonad reads raw KeyCode and then converts it to unmodified
KeySym, while these modules used `lookupString` to find the actual
keysyms. As a consequence, key definitions like `(shiftMap, xK_Tab)`
didn't work on many layouts because an actual KeySym for `Shift-Tab` is
commonly `ISO_LEFT_TAB`, and not `Tab`.
Closes: https://github.com/xmonad/xmonad-contrib/pull/590
Co-authored-by: Tomas Janousek <tomi@nomi.cz>
This replaces the custom `cleanMask` extension in these modules—which
only filtered out XKB group bits and Button5Mask¹—with the new
`cleanKeyMask` which additionally filters out all mouse buttons, as
these aren't relevant for key bindings.
¹) Filtering out Button5Mask was probably an off-by-one mistake.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/290
Related: https://github.com/xmonad/xmonad-contrib/pull/590
We didn't clean XKB group bits out of the KeyPress events' state so key
bindings only worked in the primary keyboard layout (first XKB group).
To fix this, this adds a `cleanKeyMask` function to X.Prelude which is
analogous to `cleanMask` but aimed at cleaning regular KeyPress states
(as opposed to just KeyPresses from passive key grabs), and this is then
used instead of `cleanMask`.
Related: https://github.com/xmonad/xmonad-contrib/issues/290
Related: https://github.com/xmonad/xmonad-contrib/pull/590
There's no reason (other than me forgetting to update the docs when
these add-Hooks were added) to steer users towards the ugly record-based
low-level API.
Add a `visualSubmap` function, which works much like the regular
`submap` one, except that it visualises the available choices in a
pop-up window.
Related: https://github.com/xmonad/xmonad-contrib/issues/472
Adds several new functions and type for manipulating "simple windows".
There are several ways to draw windows in X.U.XUtils and other places
already, but they are all quite manual. Most of the time one does not
want to think about dimensions much and assumes that the code is smart
enough to "figure it out"; this is an attempt to do exactly that.
There is a less-managed version `showSimpleWindow`, which just creates
and shows the windows, as well as a wrapper-like `withSimpleWindow` that
also destroys the window once some action finishes executing.
With these functions it should be possible to refactor some contrib
modules that currently draw windows manually, like X.U.EasyMotion.
This technically introduces a regression with regards to the way that
modifier masks are printed in X.U.NamedActions and X.H.DebugEvents.
However, since this way of printing masks is move in line with
X.U.EZConfig, I personally don't think that this is noteworthy.
