[xmonad] `Status' Package [xmonad-contrib]

[vrs]

Quoting Matt Walker (2015-12-13 18:49:59)
> [Evidence of Problem]
> 
> People with advanced XMonad/Dzen2 setups often resort to using two
> different Dzen2 bars -- one for XMonad stuff that XMonad controls, and one
> that is piped output from something like Conky.  Here are just a few
> examples I've found around the web:
> 
> https://wiki.haskell.org/Xmonad/Config_archive/And1's_xmonad.hs (note the
> hacky (but effective) use of the DynamicLog PP facilities)
> https://wiki.haskell.org/Xmonad/Config_archive/Regalia's_xmonad.hs
> https://wiki.haskell.org/Xmonad/Config_archive/Thayer_Williams'_xmonad.hs
> https://wiki.haskell.org/Xmonad/Config_archive/avendael's_xmonad.hs
> http://thinkingeek.com/2011/11/21/simple-guide-configure-xmonad-dzen2-conky/
> https://github.com/davidbeckingsale/xmonad-config/blob/master/xmonad.hs
> 
> In each of these cases, the status bar has two parts: one part controlled
> by XMonad that deals with the WM state, and another part controlled by
> Conky that contains the system state.  The premise of my argument is
> basically that this is undesirable, and all information should be available
> from, and outputted from, xmonad.  We have a Haskell environment, and we
> are completely by-passing it!
I have something similar (unpublished) with two xmobars, but I do this
because I essentially ran out of space to display all the info I want to
display. One top xmobar per screen that displays workspace info, current
directory (heavily integrated with topicspaces) and window titles (that
took some hacking), and a bottom one on the main screen for system info.

> For example, say I wanted my current layout and window-name information
> printed in the middle of the bar, and my list of workspaces printed on the
> left side of the bar.  This is difficult to achieve with the current tools
> -- one must be aware of the formatting characters when performing the
> translation if one wants the text to be correctly justified/centred.  One
> must be quite familiar with which parts of the PP get outputted when and
> how they are put together (since we want two fields to be output to the
> same region, but centring them both would make them overlap.)  This makes
> for a brittle and non-general solution to the problem.
To add to this: xmobar doesn't interpret separators in the output piped
to it at all.

> The problem is that DynamicLog's PP facility is not extensible in any
> elegant way.  You have to know how the whole thing works to be able to
> extend it, even in minor ways.  Modifications to it are neither composable,
> nor factorable -- I can't just add or remove customizations without it
> probably breaking.
Hm works for me? You just need to be able to use ppExtras, the rest can
be entirely custom. I do agree that the code is quite specific to your
status bar though.

> We define the `length' of a StatusText to be the length of the content.
> This allows us to calculate offsets within the status bar without having to
> strip away all the markup.
That is neat but it takes only an application of shorten in the right
place, namely before adding all the markup.

> I have a library included in Status.DZen2 (name change is coming to get rid
> of the capital Z).  It contains combinators and so on for marking up
> StatusText using all the dzen2 commands, all from within XMonad.
> Exciting!  I plan to make a universal interface and a fancy interface: the
> universal interface will contain all commands common to dzen2, xmobar, and
> possibly taffybar.  In this way, it will be possible to swap out your
> statusbar without everything breaking.  Maybe I'll abandon this part, but
> let me know if it sounds cool to you.
Well to be honest I would expect such a migration to involve a certain
amount of work regardless of the way my xmonad output is formatted - for
example I'd need to migrate all my system information scripts and maybe
write some new ones. The formatting would be a minor problem.

> [Conclusion]
> 
> I'd love to hear some feedback on this.  Does anyone even care?  Maybe this
> is better left as just a personal package for myself.  I have no idea.  I
> just felt it solved a rather general problem, and so could possibly be of
> use to other people.  If it helps reduce the (in my opinion) ugly hacky use
> of Conky and 2+ dzen bars, then I think that's pretty good.  Let me know!
I'm interested, but so far I see nothing that would make me migrate. The
most difficult part for me as a relative haskell noob was to get getName
to behave and generally get all the desired info out of xmonad in the
first place. Formatting was verbose to do but not particularly difficult.
Personally, the first place I'd improve would be the xmobar config
parser (not applicable to your usecase).

Cheers,
vrs

PS: since you're familiar with dzen and its syntax, you may want to look
at this commit and check whether dzenstrip has a similar issue:
<https://github.com/xmonad/xmonad-contrib/commit/0a7ae19f90ceeac609f71eccd47cd3e07c4e5f25>