[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
Quoting Matt Walker (2015-12-13 18:49:59) 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/0a7ae19f90ceeac609f71eccd47c...