- 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.
Currently, the ppUrgent method is an addition to the ppHidden method.
This doesn't make any sense since it is in fact possible to get urgent
windows on the current and visible screens. So I've raised the ppUrgent
printer to be above ppCurrent/ppVisible and dropped its dependency on
ppHidden.
In addition to that this makes it a lot more easier to define a more
custom ppUrgent printer, since you don't have to "undo" the ppHidden
printer anymore. This also basicly removes the need for dzenStrip,
although I just changed the description.
-- McManiaC / Nils
Most users would expect workspaces with urgent windows to be highlighted in
xmobar when they set up an UrgencyHook. Hence, doing this by default in xmobarPP
makes sense. (dzenPP does the same)
This function was written by Wirt Wolff. This change should allow UrgencyHook
to work out of the box with dzen and dzenPP, rather than the colours being
overridden so even though UrgencyHook is working, it doesn't change colours.
