can xmonad's logHook be run at set intervals rather than in (merely) response to layout events?

Question

I'm using dynamicLogWithPP from XMonad.Hooks.DynamicLog together with dzen2 as a status bar under xmonad. One of the things I'd like to have displayed in the bar is the time remaining in the currently playing track in audacious (if any). Getting this information is easy:

audStatus :: Player -> X (Maybe String)
audStatus p = do
  info <- liftIO $ tryS $ withPlayer p $ do
                ispaused <- paused
                md <- getMetadataString
                timeleftmillis <- (-) <$> (getCurrentTrack >>= songFrames) <*> time
                let artist = md ! "artist"
                    title = md ! "title"
                    timeleft = timeleftmillis `quot` 1000
                    (minutes, seconds) = timeleft `quotRem` 60
                    disp = artist ++ " - " ++ title ++ " (-"++(show minutes)++":"++(show seconds)++")" -- will be wrong if seconds < 10
                    audcolor False = dzenColor base0  base03
                    audcolor True = dzenColor base1 base02 
                return $ wrap "^ca(1, pms p)" "^ca()" (audcolor ispaused disp)
  return $ either (const Nothing) Just info

So I can stick that in ppExtras and it works fine—except it only gets run when the logHook gets run, and that happens only when a suitable event comes down the pike. So the display is potentially static for a long time, until I (e.g.) switch workspaces.

It seems like some people just run two dzen bars, with one getting output piped in from a shell script. Is that the only way to have regular updates? Or can this be done from within xmonad (without getting too crazy/hacky)?

ETA: I tried this, which seems as if it should work better than it does:

1. create a TChan for updates from XMonad, and another for updates from a function polling Audacious;
2. set the ppOutput field in the PP structure from DynamicLog to write to the first TChan;
3. fork the audacious-polling function and have it write to the second TChan;
4. fork a function to read from both TChans (checking that they aren't empty, first), and combining the output.

Updates from XMonad are read from the channel and processed in a timely fashion, but updates from Audacious are hardly registered at all—every five or so seconds at best. It seems as if some approach along these lines ought to work, though.

Answer 1

I know this is an old question, but I came here looking for an answer to this a few days ago, and I thought I'd share the way I solved it. You actually can do it entirely from xmonad. It's a tiny bit hacky, but I think it's much nicer than any of the alternatives I've come across.

Basically, I used the XMonad.Util.Timer library, which will send an X event after a specified time period (in this case, one second). Then I just wrote an event hook for it, which starts the timer again, and then manually runs the log hook.

I also had to use the XMonad.Util.ExtensibleState library, because Timer uses an id variable to make sure it's responding to the right event, so I have to store that variable between events.

Here's my code:

{-# LANGUAGE DeriveDataTypeable #-}

import qualified XMonad.Util.ExtensibleState as XS
import XMonad.Util.Timer

...

-- wrapper for the Timer id, so it can be stored as custom mutable state
data TidState = TID TimerId deriving Typeable

instance ExtensionClass TidState where
  initialValue = TID 0

...

-- put this in your startupHook
-- start the initial timer, store its id
clockStartupHook = startTimer 1 >>= XS.put . TID

-- put this in your handleEventHook
clockEventHook e = do               -- e is the event we've hooked
  (TID t) <- XS.get                 -- get the recent Timer id
  handleTimer t e $ do              -- run the following if e matches the id
    startTimer 1 >>= XS.put . TID   -- restart the timer, store the new id
    ask >>= logHook.config          -- get the loghook and run it
    return Nothing                  -- return required type
  return $ All True                 -- return required type

Pretty straightforward. I hope this is helpful to someone.

Answer 2

It cannot be done from within xmonad; xmonad's current threading model is a bit lacking (and so is dzen's). However, you can start a separate process that periodically polls your music player and then use one of the dzen multiplexers (e.g. dmplex) to combine the output from the two processes.

You may also want to look into xmobar and taffybar, which both have better threading stories than dzen does.

With regards to why your proposed TChan solution doesn't work properly, you might want to read the sections "Conventions", "Foreign Imports", and "The Non-Threaded Runtime" at my crash course on the FFI and gtk, keeping in mind that xmonad currently uses GHC's non-threaded runtime. The short answer is that xmonad's main loop makes an FFI call to Xlib that waits for an X event; this call blocks all other Haskell threads from running until it returns.