The EWMH support added in 7e9c986217 only added handling of
_NET_WM_STATE_DEMANDS_ATTENTION to handleEvent and cleanupUrgents, but
manual urgency clearing via clearUrgents or automatic urgency clearing
via filterUrgencyHook was left without EWMH support. This commit adds
the missing pieces.
Fixes: 7e9c986217 ("Add EWMH DEMANDS_ATTENTION support to UrgencyHook.")
Atoms are at most 32-bit even on 64-bit platforms, per the X protocol,
despite them being stored in a CLong. Even if they weren't (and they
are, see /usr/include/X11/Xproto.h and
https://stackoverflow.com/a/23265984/3407728), xmonadctl isn't unpacking
the CLong into multiple data items.
- StatusBarConfig serves as an abstraction over status bars. This
enables users to customize their status bars without having to do
the plumbing themselves.
- Multiple status bars can be used directly thanks to the
StatusBarConfig, which provides a way to compose status bars
In order to effectively restart status bars without relying
on pipes, spawnStatusBarAndRemember saves the PID of status
bars to kill them with cleanupStatusBars.
Removed checking for docks
Cleaned imports
Use signalProcesGroup instead of inverting the PID
Updated the documentation
Updated the documentation
Stop recommending pipes as the best/first thing to do and instead
recommend property based logging for all bars that support it. Also
strongly recommend users to use the already pre-made functions that do
all of the plumbing.
Add comments for the arguments of the most important user-facing
functions.
In an effort to modernize XMonad.Hooks.DynamicLog (and thus to stop
recommending pipes as the best way to interface with xmobar), implement
property log based solutions for the most important functions. Sadly
dzen does not seem to support this kind of interfacing with xmonad.
The descriptions of xmobar, statusBar, and statusBar' have been updated
to reflect that they should be seen as secondary choices.
Starting with 5240116f3c we only support
GHC versions 8.4.4 and up (more precisely, the GHC version associated
with stackage lts-12 and up). The imports in question are now in
Prelude and need not be imported explicitly.
This makes docksStartupHook unnecessary. That is desirable because we
didn't add a changelog entry about it being necessary, and 4 years after
its introduction we still have users grabbing old configs and reporting
(https://github.com/xmonad/xmonad/issues/21#issuecomment-596161669) that
ManageDocks doesn't work properly.
I would love to finally settle this.
Full story follows:
xmonad-contrib 0.12 introduced (00be056a1b, merged in April 2013)
caching to ManageDocks to avoid queryTree calls on every runLayout,
which brought in several bugs. Attempts to fix these bugs in
xmonad-contrib 0.13 introduced (28e9f8bce7, merged in February 2016) a
breaking change in ManageDocks that required users to add
docksStartupHook (or docks, after e38fb3bdb8 got merged in November
2016) to their configs for avoidStruts to still work after xmonad
restart. Unfortunately this was never mentioned in the changelog nor in
any compilation warning (which get discarded by xmonad --recompile
anyway !!!), so as of March 2020 we still have users being bitten by
this.
Back in September 2016 in a discussion about other bugs introduced in
28e9f8bce7 I suggested that we use Maybe to indicate whether the cache
had been initialized and initialize it on demand when it had not.
Unfortunately I wasn't sufficiently clear about what I meant and Brandon
was going through some health issues, so we just got into a heated
argument and ended up merging a suboptimal solution. :-(
And since we're _still_ getting complaints from users every now and
then, I believe it's worth dealing with even after all these years.
If nothing else, let this serve as a reminder that breaking users'
configs without any warning is wrong.
(Oh and we should probably stop hiding xmonad.hs compilation warnings,
otherwise we can't ever hope to provide smooth deprecation and upgrade
paths.)
Fixes: 00be056a1b ("Cache results from calcGap in ManageDocks")
Fixes: 28e9f8bce7 ("add docksStartupHook for handling docks when restarted")
Fixes: e38fb3bdb8 ("Make usage of ManageDocks simpler and more robust")
Related: https://github.com/xmonad/xmonad-contrib/issues/118
Related: https://github.com/xmonad/xmonad-contrib/pull/30
Related: https://github.com/xmonad/xmonad-contrib/pull/80
Related: https://github.com/xmonad/xmonad/issues/21
None of these properties are currently being set when xmonad starts:
_NET_ACTIVE_WINDOW(WINDOW): window id # 0x0
_NET_CURRENT_DESKTOP(CARDINAL) = 0
_NET_CLIENT_LIST_STACKING(WINDOW): window id #
_NET_CLIENT_LIST(WINDOW): window id #
because the caching introduced in 92fe5f34ff initializes the
cache with the same values that they should have in an empty session, so
we don't detect a change and don't set them.
Fix it by initializing the cache with impossible (or at least extremely
improbable) values.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/363
- By default window activation does nothing.
- `activateLogHook` may be used for running some 'ManageHook' for
activated window.
- `activated` predicate may be used for checking was window activated or
not.
Add a statusBar' function that accepts pretty printing options embedded
in the X monad, so users can leverage dynamic printing modifiers, such
as workspaceNamesPP.
Provide a way to advertise _NET_WM_STATE_FULLSCREEN in _NET_SUPPORTED.
I had this hardcoded for a while but read the mpv manpage recently:
Specifically, yes will force use of NetWM fullscreen support, even
if not advertised by the WM. This can be useful for WMs that are
broken on purpose, like XMonad. (XMonad supposedly doesn't advertise
fullscreen support, because Flash uses it. Apparently, applications
which want to use fullscreen anyway are supposed to either ignore
the NetWM support hints, or provide a workaround. Shame on XMonad
for deliberately breaking X protocols (as if X isn't bad enough
already).
I'm not sure Flash is still a good reason these days to not advertise
fullscreen support yet still handle it and look like idiots while doing
so. (And if anyone thinks it is a good reason, their unchanged xmonad
config will continue behaving that way.)
