Archives / Search ›

Growl and Pester repeating alarms

Back in October, a Pester user sent me this email:

I work in media and I like to set recurring Growl reminders to save my work. Why Growl? Because I don’t want to actually be interrupted to dismiss the Pester alarm window, only see a reminder so I can hit Command+S and continue on my way.

If I set a recurring alarm that repeats and notifies with Growl (screenshot 1), the alarm will be listed in the Alarms List (screenshot 2).  However, it will only display the alert once and then not repeat and the recurring alarm will not show up again in the Alarms List (screenshot 3).  If I quit Pester and then reopen the Alarms List, the alarm will be listed again (screenshot 4) but after it displays that one time, it will not show up again.

I have tried upgrading Pester’s Growl framework to 1.3.1 using the Growl Version Detective, but that did not work.

At the time I responded that I could not reproduce the problem and promised to get back to it. I received another similar email today and finally had a chance to investigate.

Unfortunately, the problem is a bug in Growl 2.0.x and 2.1 that affects repeating Pester alarms for which you have Notify with Growl selected but not Display message and time.

Pester’s repeating (periodic) alarms work somewhat uniquely: if you’ve got an alarm set to trigger every 5 minutes, the 5 minutes don’t start until the previous repetition of the alarm finishes expiring. An alarm can finish expiring in one of several ways:

  1. If Display message and time is selected, the user clicks Snooze or Dismiss.
  2. If Display message and time is not selected, the user chooses Stop Alerts from Pester’s Alarm menu or presses ⌘. (Command-period) (and #1, if necessary)
  3. If Display message and time is not selected, all of the alarm’s selected alerts (voice, media, speech and/or Growl) complete or are dismissed by the user. For images or movies, the user can close the display window.

Growl promises to inform clients, such as Pester, when the user clicks on a notification, and when a notification times out (e.g., disappears from the screen). But Growl 2.0.x and 2.1 don’t do this, so Pester waits forever for the notification to time out or be clicked, the Growl alert never completes, and the alarm never finishes expiring. Alarms which are in the process of expiring aren’t listed in the Alarms window, which explains the behavior described above in which alarms disappear from the list.

My apologies if you’ve experienced this problem.  If you have repeating alarms “stuck” which you can’t delete, you can force an alarm that is waiting forever for Growl to appear in the alarm list with Stop Alerts (⌘.).

Update: Pester 1.1b16 supports OS X notifications in 10.8 Mountain Lion and later, in addition to Growl notifications.  Unlike Growl, OS X notifications don’t even promise to provide any information about when they disappear from the screen, so Pester won’t wait for them. Pester 1.1b16 works around the problem by making Growl notifications behave the same way as OS X notifications when you are using Growl 2.0 or later — they won’t wait for you to dismiss them.  When a fixed version of Growl is available, I will revisit this issue.

7 comments on “Growl and Pester repeating alarms”

  1. 7 August 2013 | 7:27 PM

    Or you could contact us. :)

    We’ll have a new SDK out this week that we’ve been beta testing for a while, clicks work fine there. It’ll be worth a go on that one to try it out.

    Chris Forsythe

  2. 7 August 2013 | 7:34 PM

    Cool, good to know. (I did respond to the thread on Google Groups, but I think my post might be stuck in moderation.)

  3. 7 August 2013 | 7:42 PM

    Ah, yep. I approved it earlier but now everything makes sense as to who was sending it.

    We’ll get you onto the new SDK, see if that helps, and go from there. If you’re handy at irc we’re on freenode in #growl by the way.


  4. ssp
    11 August 2013 | 3:11 PM

    Hi Nicholas,

    the post made me curious about peeking at the repository to see whether current development versions allow using Notification Center already. Unfortunately building didn’t work for me (seemingly because I don’t have Growl installed). So before I end up cursing Xcode too much I’m wondering when b16 will be out…

    (I guess a fool-proof project would be nice as well.)

  5. 11 August 2013 | 3:39 PM

    Indeed, Notification Center support is in the latest version from Git. There are two things that are stopping me from releasing the current version:

    1. The way I handle failure to restore alerts is not only not recommended (using ObjC exceptions) but is also potentially dangerous (I’ve seen intermittent crashes on startup). As I start to add features that are only supported on some OS versions, this becomes a bigger issue. This has been on my to-do list for years, and I need to rewrite this using NSError (and probably

    2. My Apple developer account is broken (long story which is partially NDA-encumbered, mostly discussed on Twitter) and I managed to accidentally install Mavericks over my only copy of my my existing private key, so I need to buy a new membership to sign Pester. I’m extremely irritated about the lack of responsibility Apple has shown here, which is contributing to my reluctance to spend money.

    The way I build Pester currently is pretty strange — with the 10.6 SDK on Xcode 4.6.3 (which only works because it’s a 32-bit app). I think it should compile against the 10.8 SDK too, but excising Growl will be a bit harder (currently I’m using the 1.2.3 framework but will have to move to a newer version once the above-mentioned fix goes in).

    Upshot: I’ll email you a link to a built version.

  6. ssp
    11 August 2013 | 4:18 PM

    Thanks for mailing the built version :)

    I probably don’t even want to know about the details of point 2. (My understanding is that you don’t really need the Apple certificate anyway unless you want to trouble yourself with iCloud…) Nor do I want to know about the build details (my impression is that especially once you start dealing with different SDKs and so on you easily spend as much time trying to tame Xcode as you spend doing useful programming… personally I’ve mostly just given up on even trying).

  7. 11 August 2013 | 5:30 PM

    You shouldn’t need to buy a new dev account to get a new sandbox friendly signing certificate as far as I’m aware. Have you tried setting up for generating a new signing cert via the new membercenter portal?

Leave a reply