DynamicLog improvements and new contrib module, XMonad.Util.Loggers
Hi everyone! Just a quick description of a patch I just pushed to the xmonad-contrib darcs repo. First, I cleaned up DynamicLog and added a bunch of documentation and examples -- getting a working status bar seems like one of the more difficult aspects of a typical xmonad setup, so hopefully this will go some ways towards fixing that. In another step to make setting up a useful status bar easier, I also added a new field to the PP record, ppExtras. This is a list of 'loggers', i.e. (X (Maybe String)) actions, which will be run each time the status is generated, and their output added to the normal window title + layout + workspace information. As an example of the sorts of things you can put there, and as a repository for useful loggers that people might create, I also added a new module, XMonad.Util.Loggers. The upshot of all this is that I used to have a separate script to get the time and date, battery information, and load averages, into which I would pipe the output of xmonad, and then pipe the output of that script into dzen. Now, I no longer have a separate script, I can just throw a few loggers in the ppExtras field of my PP format, and hey presto! Simpler, easier to maintain, and easier for newcomers to figure out. If you find the new ppExtras feature useful, I hope you'll create some new Loggers and put them in the Loggers module. And feel free to improve upon/generalize the ones that are already there. Ideally there should be a wide array of useful, configurable loggers that new users can choose from when constructing their preferred status bar. happy xmonading, -Brent
On Tue, Feb 19, 2008 at 04:50:15PM -0500, Brent Yorgey wrote:
Just a quick description of a patch I just pushed to the xmonad-contrib darcs repo. First, I cleaned up DynamicLog and added a bunch of documentation and examples -- getting a working status bar seems like one of the more difficult aspects of a typical xmonad setup, so hopefully this will go some ways towards fixing that.
In another step to make setting up a useful status bar easier, I also added a new field to the PP record, ppExtras. This is a list of 'loggers', i.e. (X (Maybe String)) actions, which will be run each time the status is generated, and their output added to the normal window title + layout + workspace information. As an example of the sorts of things you can put there, and as a repository for useful loggers that people might create, I also added a new module, XMonad.Util.Loggers. The upshot of all this is that I used to have a separate script to get the time and date, battery information, and load averages, into which I would pipe the output of xmonad, and then pipe the output of that script into dzen. Now, I no longer have a separate script, I can just throw a few loggers in the ppExtras field of my PP format, and hey presto! Simpler, easier to maintain, and easier for newcomers to figure out.
If you find the new ppExtras feature useful, I hope you'll create some new Loggers and put them in the Loggers module. And feel free to improve upon/generalize the ones that are already there. Ideally there should be a wide array of useful, configurable loggers that new users can choose from when constructing their preferred status bar.
happy xmonading,
And so your plan of world domination has been eventually revealed! You want to get rid of the very reasons why xmobar had to be written! I'll fight it to death!! ;) I'm just kidding... very nice idea, indeed. Just one question: why Maybe String? I had a very quick read at your code, but as far as I understand using 'catMaybes' means that 'Just []' and 'Nothing' have the very same meaning. Am I wrong? Cheers, Andrea
On Wed, Feb 20, 2008 at 08:24:57AM +0100, Andrea Rossato wrote:
On Tue, Feb 19, 2008 at 04:50:15PM -0500, Brent Yorgey wrote:
Just a quick description of a patch I just pushed to the xmonad-contrib darcs repo. First, I cleaned up DynamicLog and added a bunch of documentation and examples -- getting a working status bar seems like one of the more difficult aspects of a typical xmonad setup, so hopefully this will go some ways towards fixing that.
In another step to make setting up a useful status bar easier, I also added a new field to the PP record, ppExtras. This is a list of 'loggers', i.e. (X (Maybe String)) actions, which will be run each time the status is generated, and their output added to the normal window title + layout + workspace information. As an example of the sorts of things you can put there, and as a repository for useful loggers that people might create, I also added a new module, XMonad.Util.Loggers. The upshot of all this is that I used to have a separate script to get the time and date, battery information, and load averages, into which I would pipe the output of xmonad, and then pipe the output of that script into dzen. Now, I no longer have a separate script, I can just throw a few loggers in the ppExtras field of my PP format, and hey presto! Simpler, easier to maintain, and easier for newcomers to figure out.
If you find the new ppExtras feature useful, I hope you'll create some new Loggers and put them in the Loggers module. And feel free to improve upon/generalize the ones that are already there. Ideally there should be a wide array of useful, configurable loggers that new users can choose from when constructing their preferred status bar.
happy xmonading,
And so your plan of world domination has been eventually revealed! You want to get rid of the very reasons why xmobar had to be written! I'll fight it to death!! ;)
I'm just kidding... very nice idea, indeed.
Just one question: why Maybe String? I had a very quick read at your code, but as far as I understand using 'catMaybes' means that 'Just []' and 'Nothing' have the very same meaning. Am I wrong?
Cheers, Andrea
Of course xmobar is still a better solution in most cases -- the ppExtras are only printed each time there is a windowset change, which would mean that the displayed data may become very stale! I'm not sure that we should recommend ppExtras for clocks and such for this reason. Cheers, Spencer Janssen
On Wed, Feb 20, 2008 at 4:18 AM, Spencer Janssen
Of course xmobar is still a better solution in most cases -- the ppExtras are only printed each time there is a windowset change, which would mean that the displayed data may become very stale! I'm not sure that we should recommend ppExtras for clocks and such for this reason.
Hmm, good point! I hadn't really thought of that... -Brent
On Wed, Feb 20, 2008 at 2:24 AM, Andrea Rossato
And so your plan of world domination has been eventually revealed! You want to get rid of the very reasons why xmobar had to be written! I'll fight it to death!! ;)
I'm just kidding... very nice idea, indeed.
Muahahaha!!! Hehe, of course, that's not really my intention. Rest assured that my REAL plan of world domination has yet to be revealed. As Spencer points out, there are still good reasons to use xmobar.
Just one question: why Maybe String? I had a very quick read at your code, but as far as I understand using 'catMaybes' means that 'Just []' and 'Nothing' have the very same meaning. Am I wrong?
Hmm... well, using 'catMaybes' doesn't do that: catMaybes [Just "abc", Nothing] --> ["abc"], but catMaybes [Just "abc", Just ""] --> ["abc", ""]. But in the end I guess you're right, since the status bar output function filters out the empty string (in particular the "sepBy" function filters out the null string). I didn't realize this before, and I wonder whether it is really the correct behavior. My intention was to allow for two different cases, one in which a logger does not want to output anything (or gives an error), and another in which the logger explicitly wants to output the empty string. For example, maybe you have a logger which only outputs something some of the time, but when it is not outputting anything you still want a blank space where it would have been. I don't know, it's not really very important either way, I guess. =) -Brent
On Wed, Feb 20, 2008 at 07:04:33AM -0500, Brent Yorgey wrote:
Hmm... well, using 'catMaybes' doesn't do that: catMaybes [Just "abc", Nothing] --> ["abc"], but catMaybes [Just "abc", Just ""] --> ["abc", ""]. But in the end I guess you're right, since the status bar output function filters out the empty string (in particular the "sepBy" function filters out the null string). I didn't realize this before, and I wonder whether it is really the correct behavior. My intention was to allow for two different cases, one in which a logger does not want to output anything (or gives an error), and another in which the logger explicitly wants to output the empty string. For example, maybe you have a logger which only outputs something some of the time, but when it is not outputting anything you still want a blank space where it would have been. I don't know, it's not really very important either way, I guess. =)
well, I was assuming a status bar is a one line only string and so a "" is... nothing...;) I see your point: someone wanted the prompt, afair, to return a Maybe String, where a Nothing was the user exiting the prompt with Esc or so. I don't think that could be the case of a logger, though. BTW, it was Spencer who pushed me to reflect about the fact that a 'Maybe list' is usually something uselessly complicated - I used a maybe [Window] or something like that in the very first version of the prompt if I recall it correctly... Cheers, Andrea
On Wed, Feb 20, 2008 at 8:15 AM, Andrea Rossato
On Wed, Feb 20, 2008 at 07:04:33AM -0500, Brent Yorgey wrote:
Hmm... well, using 'catMaybes' doesn't do that: catMaybes [Just "abc", Nothing] --> ["abc"], but catMaybes [Just "abc", Just ""] --> ["abc", ""]. But in the end I guess you're right, since the status bar output function filters out the empty string (in particular the "sepBy" function filters out the null string). I didn't realize this before, and I wonder whether it is really the correct behavior. My intention was to allow for two different cases, one in which a logger does not want to output anything (or gives an error), and another in which the logger explicitly wants to output the empty string. For example, maybe you have a logger which only outputs something some of the time, but when it is not outputting anything you still want a blank space where it would have been. I don't know, it's not really very important either way, I guess. =)
well, I was assuming a status bar is a one line only string and so a "" is... nothing...;)
I see your point: someone wanted the prompt, afair, to return a Maybe String, where a Nothing was the user exiting the prompt with Esc or so. I don't think that could be the case of a logger, though.
Yes, that was me. =) Anyway, the question here comes down to whether it's useful to be able to distinguish between failure and success returning the empty string. Even if we decide we don't care to distinguish between them right now (since empty strings will get filtered out anyway), on principle it still just seems sort of icky and non-Haskelly to me to signal failure with the special value "". It reminds me of returning -1 from int functions in C. =P
BTW, it was Spencer who pushed me to reflect about the fact that a 'Maybe list' is usually something uselessly complicated - I used a maybe [Window] or something like that in the very first version of the prompt if I recall it correctly...
I think it depends on whether you are using a list to represent a "list of successes" (in which case Maybe [a] is not needed, since [] = no successes = failure), or to represent a singular data result (in which case the empty list is just as valid of a result as any other list, hence Maybe [a] is needed to denote possible failure). -Brent
participants (3)
-
Andrea Rossato -
Brent Yorgey -
Spencer Janssen