Growl and Applescript

The Growl forums have moved to Google Groups, this forum is read only.
Ka Ora!
Harmless
Posts: 1
Joined: Tue Feb 17, 2009 10:35 pm

Growl and Applescript

Postby Ka Ora! » Tue Feb 17, 2009 10:39 pm

I might be barking up the wrong tree, But can Growl execute an Applescript on receipt of a notification.

User avatar
boredzo
Cocoaforge Admin
Posts: 796
Joined: Mon Dec 06, 2004 7:49 am
Contact:

Re: Growl and Applescript

Postby boredzo » Sat Feb 28, 2009 5:21 am

Ka Ora! wrote:I might be barking up the wrong tree, But can Growl execute an Applescript on receipt of a notification.


Theoretically. There are a lot of limitations under the current system, though:

  • You'd have to write a Cocoa-based display to run the script.
  • It would have to be the same script every time (can't have a different script per notification, although you could write a dispatcher script that would do that).
  • It would take the place of a regular display; you couldn't run the script and also have one of the other displays show it on the screen (well, you could show the other display yourself, but you would have to implement that yourself, it would break any time we change how displays work, and you couldn't have different other displays per notification).

iNik
Harmless
Posts: 10
Joined: Sat Aug 20, 2005 4:41 pm

Re: Growl and Applescript

Postby iNik » Mon Jul 06, 2009 9:18 pm

Haven't seen any activity on this, but I thought I'd bump it up since this could be extremely valuable.

I can see how the implementation would be very challenging. Running a script is a very different thing than just displaying a notification with fixed parameters. Here's some thoughts on how to work around this limitation:

The cocoa "display style" plugin has a simple dispatcher than runs a certain handler in a script. (a la LaunchBar's handle_string() handler) It would pass along the typical Growl info: Application, alert level, image, title and message. (I may be missing some arguments)

Growl would have its own scripts folder. (e.g. /Library/Application Support/Growl/Notification Scripts/) Each script to trigger would be named after the triggering application. So any script-triggering Growl alerts from Microsoft Word would fire off the "Microsoft Word.scpt" script.The naming scheme could always be more complex to include different alert levels, triggering events and whatnot, but it's probably easier to just pass this information to the script itself and let the scripter sort out what event is triggering it and act accordingly.

I don't see the lack of non-script notifications as a problem. It's trival to notify via Growl or an alert box in AppleScript, so notification can be handled script-side. This would also avoid sending a notification that incorrectly implies a script was successfully executed.

If I knew even a small cup of Cocoa programming, I'd attack this myself, but my skills tap out at AppleScript Studio, I'm afraid. I would be more than happy to assist with design, testing, and documenting such a module if someone would be kind enough to take it on.

User avatar
boredzo
Cocoaforge Admin
Posts: 796
Joined: Mon Dec 06, 2004 7:49 am
Contact:

Re: Growl and Applescript

Postby boredzo » Mon Jul 06, 2009 10:00 pm

iNik wrote:I don't see the lack of non-script notifications as a problem.


It is.

It's trival to notify via Growl or an alert box in AppleScript, so notification can be handled script-side.


Posting a Growl notification from such a script means one of two things:

  1. Having a dedicated fake application registration and making all scripts use that. This ruins configurability.
  2. Having the script post a Growl notification as the notifying application, which will cause Growl to run the script, which will post a notification, which will cause Growl to run the script… and so on until Growl dies because it can't allocate any more memory.

And throwing up a dialog box for a Growl notification is not acceptable.

iNik
Harmless
Posts: 10
Joined: Sat Aug 20, 2005 4:41 pm

Re: Growl and Applescript

Postby iNik » Mon Jul 13, 2009 1:13 am

boredzo wrote:
iNik wrote:I don't see the lack of non-script notifications as a problem.


It is.


Then we can agree to disagree. ;)

It's trival to notify via Growl or an alert box in AppleScript, so notification can be handled script-side.


Posting a Growl notification from such a script means one of two things:

...And throwing up a dialog box for a Growl notification is not acceptable.


I think you misunderstand me. If Growl passes off a notification to an AppleScript, then the script is the actor from then on. Growl, as a notification engine, has done its job. It has notified the script. This is no different from the Mail Me notifier which is silent, but for sending an email as the notification. Any further notification is handled by the receiving email client itself.

If it were necessary to work around this, one could take the approach of the Prowl module which also posts a secondary alert, based on its own display configuration. I actually find that a bit of a kludge, albeit a necessary one if you want to selectively forward notifications to the phone depending on time, etc. A script wouldn't have those limitations since the script itself could handle these conditions.

  1. Having a dedicated fake application registration and making all scripts use that. This ruins configurability.
  2. Having the script post a Growl notification as the notifying application, which will cause Growl to run the script, which will post a notification, which will cause Growl to run the script… and so on until Growl dies because it can't allocate any more memory.


This is simply how Growl interacts with AppleScript in general -- every script must either register itself as an application of its own, or share a registration with other scripts/applications. (including the possibility of firing up a repeating Growl alert handler that will fill the screen and kill Growl in short order) Configurability is, if anything, increased since the script author has great flexibility in how they approach these issues. Again, Growl has completely finished its job once it hands "the football" to the receiving script.

Again, this is no different from Mail Me, which already hands things off to sendmail.

The benefits of this could be enormous, though. It would dramatically increase the power of Growl itself, since complex conditions could drive notification behavior. It would increase individual application power, too, since it would add triggered events to any application that supports Growl, and effectively add some level of AppleScript support to those apps that are Growl-enabled but don't have AppleScript dictionaries.

Prowl breaks some of Growl's basic structures, but has opened up a huge number of Mac apps to the iPhone's push services -- an amazing and wonderful "hack." Adding scripting support would be an equal, if not greater, increase in Growl's abilities and potential.

And, lastly, I think it's a mistake to think about how scripts can break things. We already know they can crash programs, delete files, and wreak all kinds of havoc, just like any other program. Script support would be something only attempted by fairly expert users. (Heck, a poorly written notifier plugin could do the same.)

I think it would be a shame to shoot this down out of hand because it feels like it's outside of Growl's basic structure. The potential benefits here are too great to not explore the possibilities. If you aren't the developer to do so, I'd like to try to find someone who is interested in tackling this solution.

User avatar
boredzo
Cocoaforge Admin
Posts: 796
Joined: Mon Dec 06, 2004 7:49 am
Contact:

Re: Growl and Applescript

Postby boredzo » Fri Jul 17, 2009 7:28 pm

iNik wrote:
boredzo wrote:
iNik wrote:It's trival to notify via Growl or an alert box in AppleScript, so notification can be handled script-side.


Posting a Growl notification from such a script means one of two things:

  1. Having a dedicated fake application registration and making all scripts use that. This ruins configurability.
  2. Having the script post a Growl notification as the notifying application, which will cause Growl to run the script, which will post a notification, which will cause Growl to run the script… and so on until Growl dies because it can't allocate any more memory.

...And throwing up a dialog box for a Growl notification is not acceptable.


I think you misunderstand me.


No, I didn't. You said that the script can handle providing visual notifications, either through Growl or by presenting a dialog box.

The latter is simply unacceptable: dialog boxes for notification are annoying and obtrusive, which is largely why Growl exists in the first place. The former can only be done in one of four ways:

  1. The script uses one “application” name and notification name for all of its output notifications, leaving the user unable to configure it differently for different input notifications.
  2. The script uses the application name and notification name from the input notification for the output notification, causing an infinite loop.
  3. The script uses its own “application” name, but generates the notification name from the input notification's application and notification names, causing Growl to forget about the previous notification name whenever it runs the script for a notification from a different application, because the script's new registration won't include the old name. (growlnotify suffers a similar problem when used in a similar way.)
  4. The script has one or more application and notification names mapped to its own notification names in a hard-coded mapping. It would either be unable to handle other applications, or use an additional “Other notification” notification name for them, which would cause problem #1 for notifications from those applications.

Notification action scripts should not attempt to re-post the notification or display it themselves. That way can only cause trouble.

Prowl doesn't have this problem because it's a plug-in for Growl, so it can go through the Growl Plug-in Controller and forward the notification to another display directly.

If Growl passes off a notification to an AppleScript, then the script is the actor from then on. Growl, as a notification engine, has done its job. It has notified the script. This is no different from the Mail Me notifier which is silent, but for sending an email as the notification.


Then the ease of posting some visual notification is irrelevant, since the script won't be posting one. That's actually the only good way to do this, especially once someone gets around to reworking our UI and implementation to better support multiple actions (e.g., visual display + script).

I actually find [Prowl's solution] a bit of a kludge, …


It is, and it's something we should fix in Growl with a way to specify multiple actions.

  1. Having a dedicated fake application registration and making all scripts use that. This ruins configurability.
  2. Having the script post a Growl notification as the notifying application, which will cause Growl to run the script, which will post a notification, which will cause Growl to run the script… and so on until Growl dies because it can't allocate any more memory.


This is simply how Growl interacts with AppleScript in general -- every script must either register itself as an application of its own, or share a registration with other scripts/applications.


The difference is that there, you're talking about scripts that effectively are applications: the script either really is an application, or is acting on behalf of a single other application.

The script-as-notification-action case is different, because that script would run for all notifications from all applications (that the user had set the script for).

Again, this is no different from Mail Me, which already hands things off to sendmail.


MailMe uses the Message framework, not sendmail.

Prowl breaks some of Growl's basic structures …


Uh? No it doesn't. It's a display.

And, lastly, I think it's a mistake to think about how scripts can break things.


Nobody said anything about that. The infinite loop case is an unavoidable consequence of a notification running a script posting a notification running a script posting a notification…, not (necessarily) a security hole.

If you aren't the developer to do so, I'd like to try to find someone who is interested in tackling this solution.


That'd be fine, but at least let us (you included) discuss the solution first and understand the requirements it must satisfy and the problems it must not cause.

iNik
Harmless
Posts: 10
Joined: Sat Aug 20, 2005 4:41 pm

Re: Growl and Applescript

Postby iNik » Sat Jul 18, 2009 2:01 am

Thank you for the work you've put into helping me think through the inherent problems (in the best sense of the word) a script notifier creates.

I agree with everything you've said about scripts posting notifications. I wouldn't write "noisy" scripts myself, since that would eliminate the key benefit of Growl: unobtrusiveness. I was responding to what you said, which I mistakenly assumed was stating a REQUIREMENT for scripts to notify the user somehow. I just meant that it was entirely possible for the scripter to build in some sort of notification or user interaction if they wanted to. Caveat Scripter.

So we can table that discussion, I think.

I think it would be vital to require that scripts be defined for each application, so as to simplify scripting and reduce the chance of mistakenly setting off a recursive cycle whrein a script activates a program that posts it's own notification.... I still think taking the Script Menu's named folders approach would be both simple and fairly idiot proof -- especially since it would eliminate many potential problems caused by a "default" script. (maybe just notify if there's no appropriate script to trigger?)


Return to “Growl”

Who is online

Users browsing this forum: No registered users