In [1] we changed the return type to not be an IO action and hence this
example can't work, even with an otherwise correct configuration.
[1]: 168cb6a6c3a774bc05032536e37b982cd6b4d7cc (Removed unnecessary IO)
Before https://github.com/xmonad/xmonad/commit/383ffb7 this would
bind all unbound keys to toggle struts; after it, it would bind no
keys at all. With this commit, it will check for this case and use
the default keybinding instead.
Users who intend no key to be bound should probably use `withSB`
instead, especially in light of aforementioned commit.
This applies for withSB and withEasySB, as well as statusBarProp and
statusBarPropTo, making composability better. statusBarPipe is more
awkward to use now, but that's fine
- 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.
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
- 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.
Add a statusBar' function that accepts pretty printing options embedded
in the X monad, so users can leverage dynamic printing modifiers, such
as workspaceNamesPP.
Simple extensions of the pretty printer to differentiate between empty
and non-empty visible workspaces. Analogical to the existing
functionality for hidden workspaces. Particularly useful if some
displays managed by xmonad are turned off temporarily.
The new 'ppVisibleNoWindows' function was wrapped in a Maybe data type.
Its value dafaults to 'Nothing' and 'ppVisible' is used as fallback.
This commit adds `dzenWithFlags` function for users who wish to change the
command line arguments passed to `dzen`. The behaviour of `dzen` function is
kept the same.
As it now consists of a startup hook, a manage hook, an event hook and
a layout modifier, and behaves erratically when any one component is not
included in a user's config (which happens to be the case for all
configs from xmonad-contrib 0.12 since the startup hook is a new
inclusion), it's probably wise to have a single function that adds
all the hooks to the config instead.
NB: This will need a release notes entry anyway!
The issue was that window titles, such as those set by, for example a browser,
could set the window title to display something like
<action=malicious shell command>normal title</action>
Which could be executed by xmobar (or dzen).
This adds a ppTitleSanitize which does the above functions. This way when users
override ppTitle, the benefits are not lost.
Thanks to Raúl Benencia and Joachim Breitner for bringing this to my attention.
