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!
Style guidelines should be where most people will see them. Since we
already ask people to read CONTIRBUTING.md when they submit a pull
request, putting them in there seems like the best place.
We can also drop the curious "or freer" clause from the licensing point,
much like xmonad-contrib@f39218ddb5ffeddce90f620910d5ef2c14f2b43d
already did.
Create three sections (enhancements, bug fixes, breaking changes) in
order to organise the changes for the v0.17.0 release.
As discussed in [1], the breaking changes really aren't breaking changes
to normal users. The only exception could be the GenerateManpage
change, but even that is only important for distro maintainers. Hence,
move all of these to the very back, such that we can mention exciting
features like the stack integration at the top instead.
Related: https://github.com/xmonad/xmonad/pull/340
[1]: https://github.com/xmonad/xmonad/pull/340#discussion_r734956547
* add logo and badges to make it prettier
* revamp installation sections
* update xmonad-contrib reference and move upwards
* drop other useful programs, this is in download.html
* add new Contributing section
Fixes: https://github.com/xmonad/xmonad/issues/199
While an implementation of `liftM2 (&&)` may seem like a straightforward
lift of `(&&)` into a monadic setting, it actually expands to
(<&&>) :: Monad m => m Bool -> m Bool -> m Bool
mb <&&> mb' = do
a <- mb
b <- mb'
return (a && b)
which runs both monadic effects first and then applies `(&&)`.
This is fixed by introducing a monadic version of `if-then-else` (which
is also exported due to its usefulness) that checks the second result
only if this is explicitly necessary.
Turns out there was another aspect of `broadcastMessage` behaviour that
I missed in my review of the refactor: X.L.Tabbed updates the windowset
during handleMessage (via `X.O.focus`) and expects that change to
persist (by returning `Nothing` and hoping no other layout or layout
modifier returns `Just`). That's quite a hack, but the LayoutClass
interface doesn't allow a cleaner way to do this (well, some extensible
state plus a custom event hook might work, but then the layout isn't
self-contained any more).
And since rereading workspace layouts during `modifyLayouts` would force
this back into O(n²), we might as well revert the whole refactor. :-/
Fixes: https://github.com/xmonad/xmonad/issues/329
