growl mail temp fix

[tw]

for those of you annoyed at GrowlMail's current failures, I made a workaround. this is a mail rule applescript that will send growl notifications for incoming mail (and junk mail, I think, though I haven't gotten any yet). to use it, do this:

1. open the script editor and copy the code below into a new script
2. run it once from the script editor to register the script with growl (you can now configure it in Growl's system preferences)
3. save it to disk (the file name and location are not relevant, but it's probably best to put it in the mail scripts folder - ~/Library/Scripts/Applications/Mail)
4. Open Mail preferences and create a new rule with the condition "every message" and the action "run applescript" with a link to the script you just saved

in some ways this might be much more versatile than GrowlMail, though I'm not sure what problems will crop up with it. if you try it, tell me what goes wrong or what you'd like it to do instead, and I'll try to revise it.

Code: Select all

tell application "GrowlHelperApp"
   set the allNotificationsList to {"Mail", "Junk Mail"}
   set the enabledNotificationsList to {"Mail", "Junk Mail"}
   register as application "Growl Mail Rule" all notifications allNotificationsList ¬
      default notifications enabledNotificationsList ¬
      icon of application "Script Editor"
end tell

using terms from application "Mail"
   on perform mail action with messages messageList
      repeat with thisMessage in messageList
         set theSender to sender of thisMessage
         set theSubject to subject of thisMessage
         if junk mail status of thisMessage is true then
            set noteType to "Junk Mail"
            
         else
            set noteType to "Mail"
         end if
         tell application "GrowlHelperApp" to notify with name noteType ¬
            title noteType description ¬
            "From: " & theSender & return & return & "Subject: " & theSubject ¬
            application name "Growl Mail Rule"
      end repeat
   end perform mail action with messages
end using terms from

[charlesarthur]

for those of you annoyed at GrowlMail's current failures, I made a workaround.

Applause for that. Works like a charm for me so far (proviso: I haven't tried it on my rejoin-IMAP mailbox, which prompted previous crashes).

One could edit it so that it wouldn't tell you about Junk Mail (who wants to know spam has arrived?). But that's fiddling on the edges.

Excellent solution. Thank you.

To devs: including this in the distribution might complicate things, but it is surely a "safe" alternative, since it relies on well-documented APIs - Applescript!

[The_Tick]

We used to ship scripts, nobody maintained them, so we removed them in 1.1.

[Montanan]

That's a great script, and it works perfectly for me ... many thanks.

Not a big deal at all, but one improvement might be to have the notification also show the first few words of the mail message itself. Not sure if that's practical, though ...

[tw]

That's a great script, and it works perfectly for me ... many thanks.

Not a big deal at all, but one improvement might be to have the notification also show the first few words of the mail message itself. Not sure if that's practical, though ...

no, that's pretty easy. just replace the "Using terms from" block like this (I've reposted the whole block, but I only added 5 lines creating the theSummary variable, and added theSummary to the 'tell application "GrowlHelperApp"' line...). this grabs the first 4 lines of the content and adds it after the subject line in the notification. you can easily change it to more or fewer lines by changing the 1 thru 4 bit to whatever you like, or even change it to a word count ('words 1 thru 50 of' will give you the first 50 words).

Code: Select all

using terms from application "Mail"
   on perform mail action with messages messageList
      repeat with thisMessage in messageList
         set theSender to sender of thisMessage
         set theSubject to subject of thisMessage
         set theSummary to paragraphs 1 thru 4 of (content of thisMessage)
         set tid to AppleScript's text item delimiters
         set AppleScript's text item delimiters to return
         set theSummary to theSummary as text
         set AppleScript's text item delimiters to tid
         if junk mail status of thisMessage is true then
            set noteType to "Junk Mail"
            
         else
            set noteType to "Mail"
         end if
         tell application "GrowlHelperApp" to notify with name noteType ¬
            title noteType description ¬
            "From: " & theSender & return & "Subject: " & theSubject ¬
            & return & return & theSummary ¬
            application name "Growl Mail Rule"
      end repeat
   end perform mail action with messages
end using terms from

[tw]

We used to ship scripts, nobody maintained them, so we removed them in 1.1.

you know, it occurred to me last night that this could actually work as a permanent replacement for growlmail. the only weakness with it right now is that GrowlHelperApp doesn't have an applescript element to handle notification clicks. you'd need to add a routine to GHA to accept abstract object/application references, and update the applescript dictionary so that I can write something like 'notify with name noteType title noteType description blahblahblah application name "Growl Mail Rule" click activates whatever' and have that whatever be the object to open (complicated maybe by the fact that it has to point to an application, not the applescript sending the request). I've looked at the growl and growlmail code, and I suspect it would be non-problematic to add the kind of 'notificationwasclicked' routine you have in growlmail to the growl notify command, but I'm not enough of a cocoa programmer to do it on my own.

seems to me, though, that it would be easier to update growl's applescript abilities than to try to patch up growlmail, and you'd end up with a stabler, more versatile implementation. if you want to throw it together and have me beta test it, let me know.

right now, incidentally, a click on a notification points back to the script, and since the script can't handle an activate command this can crash growl. I'd avoid doing that...

[tw]

One could edit it so that it wouldn't tell you about Junk Mail (who wants to know spam has arrived?). But that's fiddling on the edges.

just remove "Junk Mail" from enabledNotificationsList and run the script in script editor again to re-register it. that will put an end to junk mail.

sorry, I have that there because I'm retraining my mailbox, and it didn't occur to me that most people weren't doing that - lol

[Montanan]

Again, thanks!

Because of line wraps, the default 4-line setting is giving me a pretty big notification window, but a little experimentation should be able to solve that.

I was really missing those e-mail notifications when I transitioned to Leopard, but this all works extremely well. My world is complete again.

[Montanan]

Hmmm ... setting "theSummary" variable to a word count results in a notification with each word on a separate line.

[tw]

Hmmm ... setting "theSummary" variable to a word count results in a notification with each word on a separate line.

lol - whoops. I forgot to add, if you use the words thing, you have to change this line

set AppleScript's text item delimiters to return

to

set AppleScript's text item delimiters to " "

a space might work a little better than a newline for words, ya???

[Montanan]

a space might work a little better than a newline for words, ya???

*grins*

There we go! I should have been geeky enough to figure that one out ...

[The_Tick]

We used to ship scripts, nobody maintained them, so we removed them in 1.1.

you know, it occurred to me last night that this could actually work as a permanent replacement for growlmail. the only weakness with it right now is that GrowlHelperApp doesn't have an applescript element to handle notification clicks. you'd need to add a routine to GHA to accept abstract object/application references, and update the applescript dictionary so that I can write something like 'notify with name noteType title noteType description blahblahblah application name "Growl Mail Rule" click activates whatever' and have that whatever be the object to open (complicated maybe by the fact that it has to point to an application, not the applescript sending the request). I've looked at the growl and growlmail code, and I suspect it would be non-problematic to add the kind of 'notificationwasclicked' routine you have in growlmail to the growl notify command, but I'm not enough of a cocoa programmer to do it on my own.

seems to me, though, that it would be easier to update growl's applescript abilities than to try to patch up growlmail, and you'd end up with a stabler, more versatile implementation. if you want to throw it together and have me beta test it, let me know.

right now, incidentally, a click on a notification points back to the script, and since the script can't handle an activate command this can crash growl. I'd avoid doing that...

Or we could like, you know, work on the code that we've been working on for a bit already for the new growlmail that will work better.

[tw]

We used to ship scripts, nobody maintained them, so we removed them in 1.1.

you know, it occurred to me last night that this could actually work as a permanent replacement for growlmail. the only weakness with it right now is that GrowlHelperApp doesn't have an applescript element to handle notification clicks. you'd need to add a routine to GHA to accept abstract object/application references, and update the applescript dictionary so that I can write something like 'notify with name noteType title noteType description blahblahblah application name "Growl Mail Rule" click activates whatever' and have that whatever be the object to open (complicated maybe by the fact that it has to point to an application, not the applescript sending the request). I've looked at the growl and growlmail code, and I suspect it would be non-problematic to add the kind of 'notificationwasclicked' routine you have in growlmail to the growl notify command, but I'm not enough of a cocoa programmer to do it on my own.

seems to me, though, that it would be easier to update growl's applescript abilities than to try to patch up growlmail, and you'd end up with a stabler, more versatile implementation. if you want to throw it together and have me beta test it, let me know.

right now, incidentally, a click on a notification points back to the script, and since the script can't handle an activate command this can crash growl. I'd avoid doing that...

Or we could like, you know, work on the code that we've been working on for a bit already for the new growlmail that will work better.

up to you, man, it's your software. I'm just trying to help.

this isn't to say that I understand your position, though. click handlers for your applescript implementation are something your software really ought to have regardless, the coding seems quick and painless, and once its done GrowlMail becomes redundant (because unless you put one heck of a lot of effort into redesigning GrowlMail, Mail's rule actions and applescript are always going to be more powerful, and always more stable). a little common sense might be in order on this issue...

by the way, if you'd like someone to maintain your applescripts, I'm happy to volunteer (within my time constraints). send me an email and we'll talk.

[The_Tick]

Mail rule stuff would be manual for end users, which isn't something we want to have. GrowlMail makes configuration a breeze.

Regarding the scripts, they're still in subversion, feel free to take a look at them

[evands]

Addition of a mail rule could be automated via an applescript, if installation was the only blocker for something that worked.

[bgannin]

Addition of a mail rule could be automated via an applescript, if installation was the only blocker for something that worked.

I'm unfamiliar with Mail's rule scripting so I'll just state my notes.

1) This addition would be a macro solution that adds a rule to run this AppleScript when any emails, not in junk, arrive. This precludes the addition to their existing rules, which may be what they prefer.

2) Does Mail's scripting expose the ability to set the action for the rule, and in addition, does it allow you to specify the path of the script that is executed?

[evands]

Picture is worth a thousand words. Most of my rules actually run serverside (via procmail), but here's one I happen to already have set up locally. It sends some low-traffic coding-related emails to my generic Coding folder. For the screenshot, I also added a "Run Applescript" item, just to allow easy reference in this thread.

Addition of a mail rule could be automated via an applescript, if installation was the only blocker for something that worked.

I'm unfamiliar with Mail's rule scripting so I'll just state my notes.

1) This addition would be a macro solution that adds a rule to run this AppleScript when any emails, not in junk, arrive. This precludes the addition to their existing rules, which may be what they prefer.

I'm not quite sure what this means, but it seems to me that tapping into the rather complex rules criteria which can be configured by Mail is a net win, not net loss, allowing one to take the rule which would be installed by default (any mail, not junk, received --> display growl notification) and modify it / duplicate it to set up much more complex rules.

2) Does Mail's scripting expose the ability to set the action for the rule, and in addition, does it allow you to specify the path of the script that is executed?

Yes.

From

Code: Select all

rule n [inh. item] : Class for message rules
elements
contains rule conditions; contained by application.


Code: Select all

run script (file) : If rule matches, run this AppleScript. Set to POSIX path of compiled AppleScript file. Set to empty string to disable this action


[bgannin]

I knew it could run an AppleScript from a rule, I was referencing your comment of automating the addition, which I found to be a limiting proposition.

[evands]

I knew it could run an AppleScript from a rule

Sure. I was just posting a picture to illustrate my point about the ability to use more complex criteria for determination of whether a notification should be posted or not.

I was referencing your comment of automating the addition, which I found to be a limiting proposition.

*nod* So now we see that it isn't.

If there were a public plugin API to Mail.app, a native Cocoa solution would be far preferable to an Applescript based solution. However, I begin to think that tapping into the perceived internals of Mail (having snooped via class-dump on its classes) is way more headache than it's worth. It's inherently fragile.

[tw]

I knew it could run an AppleScript from a rule, I was referencing your comment of automating the addition, which I found to be a limiting proposition.

if I may...

automating the addition of a rule in Mail can be done at a number of levels of user interaction, as you choose. the most silent mode would be pretty much like installing the current GrowlMail bundle - you run the installer script, it sets up a set of pre-defined rules and categories, installs and links the script, registers with Growl (all in the background), and then opens the growl preference list so that the user can configure growl stuff. a more vocal install would do all that, plus (say) give the user an opportunity to set up special notification types for specific tasks, or for particular address book groups or entries. beyond that it's probably not worth the effort - people who want extreme levels of control are not going to balk at modifying the rule actions or the applescript on their own.