Attached is a start. there are some reference applescripts in /Library/Scripts/Mail Scripts/Rule Actions for the mail bit and current growl applescript docs here: http://growl.info/documentation/applescript-support.php
as for how to do stuff in applescript: yes it can be frustrating at times. good example; if one wanted to get rid of the <email address> bit at the end of the sender text in the above example, this is the best i’ve found so far: http://stackoverflow.com/questions/1716440/applescript-index-of-substring-in-string :/ Josh On 7 Jul 2011, at 11:39, Richard Hamilton wrote: > > > On Thu, Jul 7, 2011 at 6:11 AM, Dylan Ryan <[email protected]> wrote: > [...] > I know, but I see it slightly differently. From my perspective, if there is a > widespread problem with just adding the new UUIDs, odds are I'll notice it > quickly after making a change. That is, extensive testing isn't necessary for > a widespread problem, cursory testing will almost certainly find it. And if > there is a highly specific problem, odds are no amount of testing I can do > will find it because I probably don't have access to the right combination of > hardware and software to trigger it anyway. That is, extensive testing isn't > helpful because odds are I do not have the right equipment to trigger it, so > why waste time trying to do the impossible? So rather than testing for a week > knowing that odds are I won't find anything, to me it seems more logical to > update the UUIDs, do a quick "does this work?" check on as much hardware as I > can, then release it as a "potentially unstable" version an hour or two after > a system update. Anyone who can't wait can use it and provide the large > testing platform that I don't have access to, but the vast majority of people > will likely find that it works because it passed the "works on my hardware so > probably works in most places" test. This seems better than waiting a week or > more to test, not finding anything, releasing a "this is stable" version, and > having the same people that would have caught the problem in the "potentially > unstable" version catch it anyway and report it. It cuts a week or more off > the wait time for people willing to take a risk (makes people happy), means > less problems on versions that are expected to be stable (makes people > happy), etc. > > Granted, for general software, that is probably the worst possible method you > could think of for pushing updates, but for such a small bundle that does > just one thing (and does it well), it seems that it would be generally > helpful. There aren't a lot of features to test, so a fairly basic "Does it > work?" type check is close to exhaustive. Especially given the track record. > As I said, as far as I have seen, I've never had a problem simply adding the > UUIDs, so that has a track record of working (or I am lucky and have a > blessed hardware/software combo that just happens to always work). Obviously, > anything could change at any time, but I still think an unstable branch that > updates fast and should work but might not, and a stable branch that almost > always does work but takes time to update (think Chrome, etc) leads to > getting updates out quicker, and if an unstable branch breaks for some people > for a few days, well, that's why it's called unstable. > > Hopefully that makes sense :) > > Does anyone know and feel free to comment whether, aside from UUIDs, the > current GrowlMail works (at least to the quick "does this work" standard) > with the 10.7 GM that's available to paid-up devs? In other words, it's one > thing if it probably has a couple years life left in it at a minimum. But it > it would need a lot more for 10.7 (and remember, Mail _is_ said to be > changing, so I wouldn't care to bet on a guess either way), then maybe some > alternative would be better. > > Either way, clickback with AppleScript would be great, if possible. And for > those of us challenged by anything as "friendly" as AppleScript (give me C++ > anytime over that!), some sample rules to approximate GrowlMail behavior > corresponding to different preference settings would be a big help, > particularly if having someone else keep GrowlMail alive turns out not to be > as straightforward as adding UUIDs, running some quick checks, and > repackaging it. > > > -- > You received this message because you are subscribed to the Google Groups > "Growl Discuss" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/growldiscuss?hl=en. -- You received this message because you are subscribed to the Google Groups "Growl Discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/growldiscuss?hl=en.
MailScript.scpt
Description: Binary data
