It's often difficult to make contrib modules work together. When one
depends on a functionality of another, it is often necessary to expose
lots of low-level functions and hooks and have the user combine these
into a complex configuration that works. This is error-prone, and
arguably a bad UX in general.
This commit presents a simple solution to that problem inspired by
"extensible state": extensible config. It allows contrib modules to
store custom configuration values inside XConfig. This lets them create
custom hooks, ensure they hook into xmonad core only once, and possibly
other use cases I haven't thought of yet.
This requires changes to xmonad core: https://github.com/xmonad/xmonad/pull/294
A couple examples of what this gives us:
* [X.H.RescreenHook](https://github.com/xmonad/xmonad-contrib/pull/460)
can be made safe to apply multiple times, making it composable and
usable in other contrib modules like X.H.StatusBar
* `withSB` from X.H.StatusBar can also be made safe to apply multiple
times, and we can even provide an API [similar to what we had
before](https://hackage.haskell.org/package/xmonad-contrib-0.16/docs/XMonad-Hooks-DynamicLog.html#v:statusBar)
if we want (probably not, consistency with the new dynamic status bars
of https://github.com/xmonad/xmonad-contrib/pull/463 is more important)
* The [X.H.EwmhDesktops refactor](https://github.com/xmonad/xmonad-contrib/pull/399)
can possibly be made without breaking the `ewmh`/`ewmhFullscreen` API.
And we will finally be able to have composable EWMH hooks.
Related: https://github.com/xmonad/xmonad/pull/294
xmobar allows you to define a list of additional fonts (additionalFonts) and to use the fn tag to choose between them. xmobarFont is essentially the same as the xmobarColor function, but for fonts.
* `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.
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.
- XMonad.Hooks.DynamicLog.PP: the pretty-printing abstracion, with the
corresponding utilities
- XMonad.Hooks.StatusBar: A new module to provide a better interface to
manage external status bars.
The silent error `user error (createFontSet)` would break certain
modules (like the prompt) by simply not showing anything.
Pango 1.44 dropped support for FreeType in favor of HarfBuzz, losing
support for traditional BDF/PCF bitmap fonts. Hence, some distributions
don't ship `xorg-fonts-misc` anymore.
Fixes https://github.com/xmonad/xmonad-contrib/issues/348
We only requested PropertyChange events from docks in the `manageDocks`
manageHook, but that only gets called for normal windows, not
override_redirect ones. Therefore, xmobar in its default configuration
wouldn't get its struts refreshed on changes. This resulted in gaps not
updating after xmobar repositions itself on xrandr changes.
If one wanted to handle that repositioning in xmonad, it was possible to
configure xmobar with `overrideRedirect = False`, which is meant for
window managers with proper EWMH stacking order support [1], so in
xmonad it resulted in xmobar covering fullscreen windows. That can be
worked around by adding `checkDock --> doLower` to manageHook, but it
starts to smell of too many workarounds.
[1]: https://specifications.freedesktop.org/wm-spec/wm-spec-1.5.html#STACKINGORDER
The fix is to request PropertyChange events for all windows that we
treat as docks.
Related: https://github.com/xmonad/xmonad-contrib/pull/490
For many (10+) years, we had a cascade of ugly workarounds:
* X.U.Run.spawnPipe returned a binary handle, so the String passed to
it must have been encoded by C.B.UTF8.String.encodeString
* X.H.DynamicLog.dynamicLogString therefore returned such an encoded
String, so one could use it directly in a hPutStrLn, but literal
Strings wouldn't work
* xmonadPropLog' also expected an encoded String to make it easier to
use together with dynamicLogString, again breaking usage with String
literals and other normal unicode Strings
Then in 1d0eaddc2530 Sibi fixed spawnPipe to return a handle usable with
normal Strings, which then obviously broke the entire cascade. But,
instead of using the opportunity to remove all the ugly workarounds, he
decided to add some more on top, so now spawnPipe with dynamicLogString
outputs doubly encoded UTF-8 and xmobar has a hack to strip this double
encoding (https://github.com/jaor/xmobar/pull/482), which only works
when XFT is in use and breaks on some long unicode codepoints. :-(
There is a better way: make everything just use normal Strings and only
encode when it goes out the wire. This means dynamicLogString can be
freely mixed with String literals, manual uses of xmonadPropLog' don't
need encodeString, and everything just works nicely.
This obviously breaks configs that used some of these pieces in
isolation (like mine), but that's a small price to pay. After all, right
now all users of spawnPipe/dynamicLogString are getting doubly encoded
UTF-8 which might or might not work in xmobar and probably breaks
horribly everywhere else, so this fix should be a clear improvement. :-)
Fixes: 1d0eaddc2530 ("Make spawnPipe to use system's locale encoding")
Fixes: https://github.com/xmonad/xmonad-contrib/issues/377
Fixes: https://github.com/jaor/xmobar/issues/476
Related: https://github.com/xmonad/xmonad-contrib/pull/334
Related: https://github.com/jaor/xmobar/pull/482
