https://github.com/xmonad/xmonad-contrib/pull/192 introduced a breaking change:
* `XMonad.Hooks.EwmhDesktops`

 `ewmh` function will use `logHook` for handling activated window. And now
 by default window activation will do nothing.
This breaking change can be avoided if we designed that a bit
differently. #192 changed `ewmhDesktopsEventHook` to invoke `logHook`
instead of focusing the window that requested activation and now
`logHook` is supposed to invoke a `ManageHook` through `activateLogHook`
which consults a global `NetActivated` extensible state to tell if it's
being invoked from `ewmhDesktopsEventHook`. This seems convoluted to me.
A better design, in my opinion, is to invoke the `ManageHook` directly
from `ewmhDesktopsEventHook`, and we just need a way to configure the
hook. Luckily, we now have `X.U.ExtensibleConf` which makes this
straightforward. So we now have a `setEwmhActivateHook`, and the
activation hook defaults to focusing the window, undoing the breaking
change.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/396
Related: https://github.com/xmonad/xmonad-contrib/pull/110
Related: https://github.com/xmonad/xmonad-contrib/pull/192
Related: https://github.com/xmonad/xmonad-contrib/pull/128
Now that we have `XMonad.Util.ExtensibleConf`, users can comfortably use
the `ewmh` combinator and still customize workspace ordering, filter out
scratchpads and expose altered workspace names.
To make this all work nicely, we introduce not one, but two
configuration options: a sort/filter function and a rename function.
This is because renaming and sorting in one go makes it hard (perhaps
even impossible) to decide which workspace to switch to upon receipt of
a _NET_CURRENT_DESKTOP request from a pager or wmctrl/xdotool. (The only
reason this wasn't a problem before is because one could pass the
renaming function to `ewmhDesktopsLogHookCustom` only, not
`ewmhDesktopsEventHookCustom`, which is a confusing hack as can be seen
in the related closed pull requests.)
Related: https://github.com/xmonad/xmonad-contrib/pull/238
Related: https://github.com/xmonad/xmonad-contrib/pull/105
Related: https://github.com/xmonad/xmonad-contrib/pull/122
For configuration values that don't compose well using a Semigroup
instance, provide a high-level API allowing arbitrary modification of
the value, taking its Default if absent. This API is only usable for
separate configuration data and cannot be used to guard addition of hook
using `once`.
This better matches the documentation.
It is still, however, considered bad practice to rely on the order of
these operations. `f` isn't meant to touch any extensible configuration.
If it happens to do so anyway, it no longer loops. :-)
Unless specified otherwise, operators in Haskell associative to the
left. However, the ergonomics of (!>) heavily lean towards the left
operand being a "single" search engine, not a combined one.
This causes trouble when not using `multi` or defining search engines
with a right fold, but (following the documentation) writing something
like
multiEngine = intelligent (wikipedia !> mathworld !> (prefixAware google))
instead. This particular definition would force the user to write
`wikipedia/mathworld:wikipedia:search-term` instead of just
`wikipedia:search-term` to access the first search engine.
Simply giving (!>) an explicit associativity fixes these problems.
When removing a workspace and distributing its windows, it's important
to remove any duplicates that may be there due to, for example, usage of
X.A.CopyWindow. X will only draw one of these window, leading to some
artifacts.
Related: https://github.com/xmonad/xmonad-contrib/issues/565
Co-authored-by: Tomas Janousek <tomi@nomi.cz>
