+ Prefer GHC 8.10.7 to 8.10.4, as versions seem to have stabilised now.
+ Add support for Stackage LTS 19; this ships with GHC 9.0.2.
+ Since a new version of 9.2 has been released, prefer 9.2.2 over 9.2.1.
Related: https://github.com/xmonad/xmonad-contrib/pull/694
Factour out the code used to detect whether a window should be floating
in Operations.hs in a new function named isFixedSizeOrTransient
Modify willFloat to use the factored out code from Opeartions.hs
When dragging and resizing windows, users may expect the cursor to
change to indicate the respective behaviour. In particular, many other
window managers already do this [1] [2].
Thus, introduce a new (non-exported) `mouseDragCursor` function that
takes a cursor shape and change the generic resize and move functions to
use that. The reason that we don't change `mouseDrag` itself (for now)
is that this is exported and quite a few contrib modules use it—breaking
compatibility with xmonad-0.17.0 so soon after the release seems unwise.
Fixes: https://github.com/xmonad/xmonad/issues/348
[1]: https://git.suckless.org/dwm/file/dwm.c.html#l1567
[2]: 7a8fa9d27a/lib/awful/mouse/resize.lua (L23)
We have had this situation happen a few times now: users update
xmonad (say, to 0.17.0) but forget that they still have an older version
installed via the distributions repositories. Features that depend on
the "bootstrap" xmonad executable to be updated (like the improved XDG
support) then fail badly.
Thus, remind users to check whether the right executable is present.
At least on Arch, none of the listed packages necessarily require that
the user has a working Xorg setup—this has already caused some confusion
for people. In particular, xmessage is very much needed in order to
show warnings and compilation errors.
During the release of xmonad 0.17.0, I realized that we need to be able
to upload candidates before tagging the release on GitHub, because there
might be issues with the tarball and Hackage may reject it. When that
happened, I had to remove the release, delete the tag, upload the
candidate manually to see what's wrong with it, try to fix it, upload it
manually again, and so on.
This commit swaps the logic: when the workflow is invoked manually, it
uploads the candidate. This can be done multiple times, and once
everything is fine, the release can finally be tagged and it's released
to Hackage proper. The only disadvantage is that we need to remember to
try uploading the candidate. Not sure if there's a perfect solution…
Many of these are legitimate, like the one in rescreen where it really
can be empty and xmonad might crash. Or the one in Main, where using an
irrefutable pattern means a pattern-match failure isn't reported using
the MonadFail instance of IO, but is left to crash later when the thunk
is evaluated.
Others are just GHC not knowing it won't crash, and we can use
Data.List.NonEmpty to tell it.
While we catch the exception that `getWindowAttributes` can throw in
`setWindowBorderWithFallback`, we immediately turn around and print the
error to stderr. Since this exception is raised every time a window is
closed[1] , it clutters stderr and may even confuse users as to why
xmonad is throwing these exceptions.
[1]: Depending on how the window is closed, we either have no way of
running `windows` on our own (say, the window is closed by a keybinding
of the program itself), or the focus change (and thus the call to
`windows`) runs before we can handle the DestroyWindowEvent.
xmonad-testing isn't really being used, so the wording needs to be
changed in CONTRIBUTING.md and in the PR template. The important thing:
we want an example for new modules/functionality, and appropriate tests.
Related: https://github.com/xmonad/xmonad/issues/341
Instead of manually compiling with `-Wall -Werror` and the like, we have
a `pedantic` flag in xmonad's cabal file with which to run the CI.
Since contributors are very unlikely to not use either stack or cabal to
build xmonad, we should refer them to this flag instead of listing all
of the options they would need to compile xmonad with in order to check
their work.
Fixes: bc8f7ff133
We install GHC using apt, so stack shouldn't install it, but should it
ever end up installing it anyway (version mismatch, version unavailable
in hvr/ghc ppa, …), we don't want it wasting valuable cache space.
Nowadays, the IRC and (since it is linked to it) matrix channels are
much faster ways to get into contact with us than the (very low traffic)
mailing list. CONTRIBUTING should reflect that, since especially new
contributors might not know where to go to get a feeling for the people
working on the project—or worse, think we only communicate via pull
requests and issues!
