Using Applescript to change Growl Display Settings

The Growl forums have moved to Google Groups, this forum is read only.
realjustinlong
Harmless
Posts: 3
Joined: Tue Jul 14, 2009 6:58 pm

Using Applescript to change Growl Display Settings

Postby realjustinlong » Sun Jul 26, 2009 8:48 pm

I am looking at creating a script to change the default display status of my growl updates based on an Applescript. I am using proximity to detect when I am with in a certain range of my computer with my phone so that it does not send me prowl updates while I am sitting at my desk. I am not to familiar with Applescripting but I have been able to set it up so far to pause my itunes when I leave and to restart when I come back.

Any help would be great

User avatar
zac
Cocoaforge Admin
Posts: 1518
Joined: Sun Mar 27, 2005 3:19 pm
Contact:

Re: Using Applescript to change Growl Display Settings

Postby zac » Sun Jul 26, 2009 8:58 pm

You could probably accomplish this by controlling the preferences like so:

To disabling using the "minimum idle time to send":

Code: Select all

defaults write com.growl.growlhelperapp net.weks.prowl.growlplugin -dict-add OnlyWhenIdle -bool NO


To enable using the "minimum idle time to send":

Code: Select all

defaults write com.growl.growlhelperapp net.weks.prowl.growlplugin -dict-add OnlyWhenIdle -bool YES


You could combine this with a very-long Prowl timeout (say, 100 minutes) to more or less simulate the behavior.

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

Re: Using Applescript to change Growl Display Settings

Postby boredzo » Sun Jul 26, 2009 9:19 pm

realjustinlong wrote:I am looking at creating a script to change the default display status of my growl updates based on an Applescript.


Growl doesn't support this.

I am using proximity to detect when I am with in a certain range of my computer with my phone so that it does not send me prowl updates while I am sitting at my desk.


You could have your script start the screen-saver when you leave your desk, and configure Prowl to only send to the server when the screen-saver is running.

If you don't like any of the screen-saver modules that come with Mac OS X, you might try GPULife.

rob3e
Harmless
Posts: 9
Joined: Sun Aug 02, 2009 1:50 pm

Re: Using Applescript to change Growl Display Settings

Postby rob3e » Sun Aug 02, 2009 2:42 pm

I was wondering the same thing. It seems like zac's idea has potential, although, for my purposes, I want to go a slightly different way. I don't care if my computer is idle or not. Sometimes it does its own thing when when I'm not around. Sometimes dogs bump the desk that wiggles the mouse that wakes up the computer. Sometimes I don't want push notifications on my iPod because I'm at a different computer that will also be getting push notifications. My thought was to tie it into the Prowl plugin setting that determines the threshold at which a Growl message is pushed to Prowl. The relevant setting is MinimumPriority. Here's my settings, and you can see that MinimumPriority is set to 0, or "normal."

Code: Select all

~/ defaults read com.growl.growlhelperapp net.weks.prowl.growlplugin
{
    ForwardNotification = 1;
    MinIdleTime = 2;
    MinimumPriority = 0;
    NotificationStyle = Smoke;
    OnlyWhenIdle = 0;
    SendWithPriority = 1;
    Username = [Username];
}


When I'm out and about, that's fine. But if I'm sitting at my desk, or at another computer that's receiving the same notifications, then they don't need to be duplicated on my iPod. The command I used:

Code: Select all

defaults write com.growl.growlhelperapp net.weks.prowl.growlplugin -dict-add MinimumPriority -int 1


That sets the forwarding threshold to "high" which filters out most of my Growl notifications. You could also set it to "extremely high," but the level of duplication I get with "high" is acceptable.

I haven't gone the extra step of Applescripting this yet. There are still a few issues to sort out:
1) the first time I tired this, I made a mess of my Growl/Prowl installation by failing to flag the setting at an integer. At least I think that was the problem. After unintalling/reinstalling both Growl and the Prowl plugin, the only thing that fixed was to rerun the command with the "-int" flag.
2) Not sure about "-dict-add." The man page makes me think this would only be needed the first time, in case the key was not already there. But I'm not sure, and would like to test leaving it out.
3) From the defaults man page:
Note: Since applications do access the defaults system while they're running, you shouldn't modify the defaults of a running application. If you change a default in a domain that belongs to a running application, the application won't see the change and might even overwrite the default.

I don't know how Growl responds to changing settings in this way while it is running. Since I broke the Prowl plugin on my first test, I guess more testing is necessary to see if Growl accepts the changes made using the defaults command while it is running. If not, perhaps the default write command could be bookended by commands to stop and restart Growl.

My solution filters Prowl notifications by priority, which is what I want to do, but if your goal is to completely turn Prowl forwarding on and off, then you could use the defaults command to write to the Growl setting, GrowlDisplayPluginName. With Prowl active, the value is set to "Prowl". I am guessing that something like:

Code: Select all

defaults write com.growl.growlhelperapp GrowlDisplayPluginName -string 'Smoke'


would switch off all Prowl notifications (although you would want to replace "Smoke" with your default Growl style) until you undid the command with:

Code: Select all

defaults write com.growl.growlhelperapp GrowlDisplayPluginName -string 'Prowl'


The "-dict-add" flag was causing errors in that setup, so I took it out and found that "default write" showed what I wanted it to, but whether I had successfully changed the Growl settings, I am not certain.

It certainly seems like the defaults command, run via Applescript, has potential to do what you/we want it to, but it needs a little more testing and/or tuning.

rob3e
Harmless
Posts: 9
Joined: Sun Aug 02, 2009 1:50 pm

Re: Using Applescript to change Growl Display Settings

Postby rob3e » Mon Aug 03, 2009 7:34 pm

So, I didn't do any test to determine whether stopping and starting Growl was necessary. I just figured that it couldn't hurt, and I found that there's a command line tool that does just that: growlctl. It is not packaged with the latest Growl installation, but it can be found in the "Extras" folder of older versions. The Growl website has an older version available for OSX 10.3.9 which contains a reportedly still functioning version of the script. Here's what I've scripted to be worked into an AppleScript if it proves functional, and, at first glance, it seems to work:

Code: Select all

growlctl stop

defaults write com.growl.growlhelperapp net.weks.prowl.growlplugin -dict-add MinimumPriority -int 1

growlctl start


Initial test was good. I had been getting regular Growl updates on Prowl. I ran the script, and the updates stopped. I forced a "high priority" Growl message, which then showed up on my iPod as a push notification. So far it seems like a winner. All that is left is to wrap it in an AppleScript.

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

Re: Using Applescript to change Growl Display Settings

Postby boredzo » Mon Aug 03, 2009 7:37 pm

I recommend using the “quit app "GrowlHelperApp"” and “launch app "GrowlHelperApp"” commands for this task. That way, you're not turning off Growl (which is what growlctl does); you're only stopping the background process.

rob3e
Harmless
Posts: 9
Joined: Sun Aug 02, 2009 1:50 pm

Re: Using Applescript to change Growl Display Settings

Postby rob3e » Mon Aug 03, 2009 9:11 pm

I don't really know what happens behind the scenes. I thought that stopping Growl was the desired result. We want Growl to completely restart so that it rereads the preferences file. Is that not the case? Or is GrowlHelperApp the program that actually reads the preference file? And is there a reason that stopping and starting Growl is less desirable than starting and stopping GrowlHelperApp?

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

Re: Using Applescript to change Growl Display Settings

Postby boredzo » Mon Aug 03, 2009 11:03 pm

rob3e wrote:I don't really know what happens behind the scenes. I thought that stopping Growl was the desired result. We want Growl to completely restart so that it rereads the preferences file. Is that not the case?


That is the case.

Or is GrowlHelperApp the program that actually reads the preference file?


Correct.

And is there a reason that stopping and starting Growl is less desirable than starting and stopping GrowlHelperApp?


That's a contradiction in terms.

GrowlHelperApp is Growl. It's the app that receives notifications from applications and displays them on the screen (or speaks them, sends them as email or SMS or to Prowl, etc.). As such, it's the app that reads the Growl preferences. That's why the Growl preferences are stored under com.growl.growlhelperapp.

`growlctl stop` turns Growl off. This is two things:

  1. Quit GrowlHelperApp.
  2. Set the preference that controls whether Growl is on or not.

If an application posts a Growl notification, it will launch GrowlHelperApp, which will read its preferences, find that you stopped it, and immediately quit without displaying the notification. We call that data loss.

`quit app "GrowlHelperApp"` only quits GrowlHelperApp—it doesn't set the preference that controls whether Growl is on. When an app launches GrowlHelperApp, GHA will read its preferences, find that it's supposed to be on, and display the notification and keep running. No data loss.

If that happens before you set Prowl's minimum-priority preference, then your command may happen while Growl is running and after it has read its preferences. Normally, doing that to an app is a bad thing because you as the user may also change its preferences within its own Preferences window, which would clobber the change you made from the script. But in your case, that's exceedingly unlikely—there's a window of milliseconds between the quit command and the defaults command in which an application would have to launch Growl and Growl would have to read its preferences. I'm not sure it's even possible without your script explicitly waiting for those things. So, in your specific case, it's not a problem worth worrying about.

rob3e
Harmless
Posts: 9
Joined: Sun Aug 02, 2009 1:50 pm

Re: Using Applescript to change Growl Display Settings

Postby rob3e » Tue Aug 04, 2009 1:56 am

Cool, thanks for explaining.

So killing GrowlHelperApp without using growlctl means no data loss, which is good, but it also means, if I'm understanding properly, that a notification sent to Growl while the preference rewriting script is running could cause GrowlHelperApp to start back up and reread the preference file before it's been changed, meaning that our preference change could be ignored. But, as you say, the time involved is so small, that it's extremely unlikely.

Still, it sounds like, allowing for an unlikely, poorly-timed notification, you have two possibilities depending on which method you use:
1) growlctl : Data loss--the message gets sent to Growl, which is not running, and set to not run, so the message is ignored.
2) quit GrowlHelperApp : Message could cause Growl to restart before the preference file is rewritten. Message will be displayed (no data loss), but preferences may be read before they are rewritten, meaning Growl will continue to operate under the old preferences.

Neither case is likely, but neither is desirable if there's alternative, so what about this:

Does Growl write to the preference file at any point other than by direct user interaction ( i.e. using the preference pane, growlctl, or defaults write)?

If not, you can run the default write command to change preference file while GrowlHelperApp is running. After the change is made you can quit GrowlHelperApp and restart it. Presumably you don't even have to restart it as it will restart itself the next time a command is sent to it, but I would probably restart it anyway for completeness. I might even restart it with a Growl notification saying that the change had been made.
It seems like, with this method, a Growl message sent while the script was in process would still be received and processed under the old preferences (no data loss), but the restart would ensure that Growl then began to operate under the new preferences.

Does this sound reasonable?

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

Re: Using Applescript to change Growl Display Settings

Postby boredzo » Tue Aug 04, 2009 3:38 am

rob3e wrote:2) quit GrowlHelperApp : Message could cause Growl to restart before the preference file is rewritten. Message will be displayed (no data loss), but preferences may be read before they are rewritten, meaning Growl will continue to operate under the old preferences.


Actually, this is even less likely than I said before. It's not notifying that launches Growl, but registering, which generally only happens when the application launches or first notifies. Once you've established your working set, you'll almost never have another registration while you're away from your computer (unless you have a cron job that uses growlnotify or something), so the chance of this happening is practically zero.

Does Growl write to the preference file at any point other than by direct user interaction ( i.e. using the preference pane, growlctl, or defaults write)?


I'm not sure. Currently, I don't think so, but I could be wrong. And, anyway, 1.2 definitely will write to its preferences at least once without your interaction if the updater is turned on, as the updater will be Sparkle starting in that version.

rob3e
Harmless
Posts: 9
Joined: Sun Aug 02, 2009 1:50 pm

Re: Using Applescript to change Growl Display Settings

Postby rob3e » Tue Aug 04, 2009 6:39 pm

So I'm still confused, but it sounds like any method we've discussed -- growlctl, quit GrowlHelperApp and restart after changing preferences, or restarting GrowlHelperApp after having changed the settings -- have very little likelyhood of causing problems because of the small amount of time involved.

But as to which way is the "best," it sounds like you're amending what you said previously about quitting GrowlHelperApp being less likely to cause data loss:

boredzo wrote:`quit app "GrowlHelperApp"` only quits GrowlHelperApp—it doesn't set the preference that controls whether Growl is on. When an app launches GrowlHelperApp, GHA will read its preferences, find that it's supposed to be on, and display the notification and keep running. No data loss.


But here you're saying that a simple "notify" from an already running application would not likely relaunch Growl, true? So in that case the potential for data loss still exists if an application sends a notification to GrowlHelperApp after it has been quit.

boredzo wrote:Actually, this is even less likely than I said before. It's not notifying that launches Growl, but registering, which generally only happens when the application launches or first notifies. Once you've established your working set, you'll almost never have another registration while you're away from your computer (unless you have a cron job that uses growlnotify or something), so the chance of this happening is practically zero.


Of course, again, this is unlikely because of the small amount of time involved, but it does indicate that there definitely needs to be a restart of GrowlHelperApp at the end of running any scripts, because waiting for the next notification may not be effective in relaunching Growl.

And even if quitting GrowlHelperApp has the same data loss risks as using growlctl, it seems like, perhaps, it's still preferable to not use growlctl because it's no longer supported, and therefore has potential to break in future updates. If the actions of growlctl are desired, I'm guessing they could be duplicated by using the "defaults write" command on the GrowlEnabled variable.

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

Re: Using Applescript to change Growl Display Settings

Postby boredzo » Tue Aug 04, 2009 8:00 pm

rob3e wrote:… as to which way is the "best," it sounds like you're amending what you said previously about quitting GrowlHelperApp being less likely to cause data loss:

boredzo wrote:`quit app "GrowlHelperApp"` only quits GrowlHelperApp—it doesn't set the preference that controls whether Growl is on. When an app launches GrowlHelperApp, GHA will read its preferences, find that it's supposed to be on, and display the notification and keep running. No data loss.


But here you're saying that a simple "notify" from an already running application would not likely relaunch Growl, true? So in that case the potential for data loss still exists if an application sends a notification to GrowlHelperApp after it has been quit.


Whoops. Yeah, you're right.

Of course, again, this is unlikely because of the small amount of time involved, but it does indicate that there definitely needs to be a restart of GrowlHelperApp at the end of running any scripts, because waiting for the next notification may not be effective in relaunching Growl.


Sure. I never suggested that you should remove the launch command from being the final step.

And even if quitting GrowlHelperApp has the same data loss risks as using growlctl, it seems like, perhaps, it's still preferable to not use growlctl because it's no longer supported, and therefore has potential to break in future updates.


Also a good point.

I would like to bring back growlctl someday, especially if more developers join the project.

If the actions of growlctl are desired, I'm guessing they could be duplicated by using the "defaults write" command on the GrowlEnabled variable.


This isn't really supported, but it should work for the foreseeable future.


Return to “Growl”

Who is online

Users browsing this forum: Majestic-12 [Bot]