GitHub Actions writes caches on the first miss and then never updates
them again. If the CI is used frequently, the caches never expire and
as they get old, become less useful.
To avoid this, force refreshing the caches once a month.
When building with an LTS version that has exactly the dependencies we
need (xmonad-0.15), stack doesn't need to download the Hackage index. If
GitHub Actions cache locking chooses this job as the one that writes the
cache, then the "stack-pantry-Linux" cache entry stays empty, possibly
forever.
Force Hackage index update to prevent this from happening.
This further reduces our usage of cache storage by caching the metadata
only once per repo. Now the metadata cache is ~250MB and the individual
caches with built dependencies are ~10M each.
Related: cfe99998fc
Related: https://github.com/xmonad/X11/pull/75
Stack installation of GHC takes more than a gigabyte, so caching it
wastes space (GitHub docs say it will be aggressively evicted after
reaching the 5G limit) and also time (compression, decompression).
Related: 9fce3805fc
Related: a5cee9bac2
Related: https://github.com/xmonad/X11/pull/75
Drop nightly and lts-15: they don't add GHC versions to the matrix and
new deps are better tested in the haskell-ci (cabal) workflow.
There's also little point in testing against both xmonad 0.15 and xmonad
master with all LTS versions. Drop most of those, reduces GitHub cache
and CPU time usage.
Related: fd243ca1c1
Related: https://github.com/xmonad/X11/pull/75
Last released xmonad doesn't build with GHC 9.0 and haskell-ci doesn't
let us tweak the test matrix easily. Let's hope the stack.yml workflow
is sufficient to test backward compat.
Related: 2a1a18023a
Current version of Steam sends _NET_ACTIVE_WINDOW ClientMessage for
every mouse click which results in a lot of border blinking.
Ignore requests that would result in no change to get rid of the
annoying border flicker that is inevitable with the current
implementation of XMonad.Operations.windows.
(Note that Steam also sends ConfigureRequest events, and these cause
an additional refresh due to the call to `float` when handling the event
in xmonad core. Not sure if worth fixing.)
Related: https://github.com/xmonad/xmonad-contrib/pull/371
Related: https://github.com/xmonad/xmonad-contrib/pull/399
- Only suggest the usage of TopicItem; this is much easier to work
with and essentially a straight upgrade to the old method.
- Use a more stripped-down example so we don't confuse beginners more
than necessary (though this is still not optimal).
Add the convenience type `TopicItem`, for easier (and safer!)
specification of topics, as well as several small helper functions to
help users work with it.
* `X.A.DynamicWorkspaceGroups`: TopicSpace support
This adds `viewTopicGroup` and a corresponding prompt. This is similar
to `viewWSGroup`, but it calls `switchTopic` instead of `W.greedyView`,
inorder to run the topic action on the workspace.
These past months I've spent a lot of time working on xmonad and I feel
like I've done a lot. This is, however, not sustainable long term. :-(
I'd like to try making my GitHub Sponsors profile a bit more visible,
hoping that would allow me to continue dedicating time to xmonad.
I know that the correct approach probably is for the xmonad project to
find a fiscal sponsor like the Software Freedom Conservancy or Open
Collective or something and accept donations as a project, and then
redistribute that to people, but I don't think the project has enough
momentum to do something as complicated as that. :-/
This is a convenience module in order to have less import noise. It
re-exports the following:
a) Commonly used modules in full (Data.Foldable, Data.Applicative, and
so on); though only those that play nicely with each other, so that
XMonad.Prelude can be imported unqualified without any problems.
This prevents things like `Prelude.(.)` and `Control.Category.(.)`
fighting with each other.
b) Helper functions that don't necessarily fit in any other module;
e.g., the often used abbreviation `fi = fromIntegral`.
A stack of stacks is a more natural representation of what SubLayouts
does: it packs information about the global focus as well as focus in
individual groups (sublayouts).
It doesn't carry information about the sublayouts themselves (but a
similar structure in X.L.Groups does), so we still use Groups and
fromGroups in some places, but future refactor can simplify that as
well, I'm sure.
My main motivation for this is that I need to expose the window groups
to the user config, and a stack of stacks seems to be a nice data
structure for that. The motivation for exposing the groups is that I
want to manipulate focus in a way that takes groups into account. As an
example, I want the following:
* mod-1, mod-2 to mod-0 switches to n-th group if not already focused,
and if focused, focus next in the group
* show these numbers and window titles in xmobar (like tmux/screen/vim
status line), like so:
1a weechat 1b browser 2 vim 3 mutt
Achieving this just using BoringWindows is quite tricky, but with the
ability to somehow (InspectLayout, which is work-in-progress, or message
with IORef) get the stack of stacks out of SubLayouts, this becomes
easy.
Turns out similar logic is already in updateGroup, and we don't even
need to worry about extra/missing windows and we can just differentiate
the result of reordering.
This makes the following sequence of operations idempotent, as it should be:
windows $ W.float w $ W.RationalRect 0 0 1 1
windows $ W.sink w
Previously, any window not visible to the SubLayout modifier (xmonad
invokes runLayout with tiled windows only) would be reordered to the end
of stack. This commit changes the reordering logic to only reorder
windows in Groups and keep all other windows where they were.
The issue was fixed upstream in 0.3.3:
24f627579124f6275791^
(it is yet to be uploaded to Hackage, Clemens lost his Hackage
credentials :-))
Related: https://github.com/xmonad/xmonad-contrib/pull/486
Related: 46f24bb27ec4 ("X.A.TreeSelect: Fix swapped green/blue in foreground when using Xft")
