How can my application read the preference settings from Growl?

[Zeflash]

Hi,

I've integrated the growl SDK in our app on OsX. I have 1 notification
that I register by returning a dictionary via the GrowlBridgeDelegate.
Now, design wants a way for the user to be able to enable / disable
the growl notification from our app, via a menu item entry. Easy
enough, I call reregister on the GrowlBridge which queries the
dictionary again, in which I removed the notification from the default
one.

Now, my question is, how do I know in my app if the user has disabled/
enabled this notification *in the growl pref pane*? The only way I can
see would be to check the growlTicket file that Growl creates for each
supported app, but that really feels like a hack.

The initial spec was to check if Growl is installed/running; if not
running the user would be able to disable the Mist notifications. If
Growl is installed, then the menu entry would make the user go to the
growl preference pane. Trouble is, Growl preferences aren't in the
system preferences anymore from 1.3 and up.

The whole thing feels a bit broken to me. It's assumed the user should
be in control of having the notifications shown or not. That was done
via the growl pref pane before. Now with Mist, we have a pseudo popup
showing in apps, but no global preference pane to access those
settings. Therefore the app needs to handle this. But then it
conflicts with the fact that if Growl is indeed installed, then it has
no way of knowing what's going on on Growl's side.

Any advice? The best / easiest solution would really be able to show
up the preference pane, independently of the installed version of
Growl.

[Joe Keenan]

Seems to me you're making this harder than it has to be.  If the user disables Growl notifications in your app, then just don't send any.

joe

[Christopher Forsythe]

I've been trying to think of a response that isn't what Joe said, but so far haven't come up with one.

Can you explain the reasoning behind what you are doing?

Chris

On Wed, Dec 14, 2011 at 11:01 PM, Joe Keenan <joe.k...@gmail.com> wrote:

Seems to me you're making this harder than it has to be.  If the user disables Growl notifications in your app, then just don't send any.

joe

--
You received this message because you are subscribed to the Google Groups "Growl Development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/growl-development/-/UWZxW-9GH9QJ.

To post to this group, send email to growl-de...@googlegroups.com.
To unsubscribe from this group, send email to growl-developm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/growl-development?hl=en.

[Joe Keenan]

Just to expand on this a little - in my apps that use Growl, I have my own "Notification" class that does all the registering with Growl and sends all the notifications.  Anywhere else in my app that wants to do a notification does so by messaging the Notification object.  So it's easy to have the UI enable/disable all notifications by setting a property in that object.

joe

[Zeflash]

The reasoning is simple; If I do what Joe says, then the disabling of
the notification is done independently of the growl preferences. This
is bad, because in that case you could have notification enabled in
the app but disable in growl, or the other way around. Either ways,
the user has to look in 2 different places to figure out why the
notifications aren't showing. It doesn't make sense.

Given I can enable or disable the growl preferences from my app to
growl, I don't see why I can't query the state of the notification. If
it was possible, the app could be aware of the settings in growl and
all would be well.

Right now, I have to handle so many different cases;
- Finding out if growl is installed - which in itself is already
*really* messy; IsRunning doesn't return true for non appStore
versions of growl! and IsInstalled always returns true. Therefore I
use an applescript to find out if the preference pane is there...
- if I figured out that growl isn't there, I keep the enable / disable
state locally and tell the SDK if I want to use Mist or not
- if I manage to figure out growl is actually there, then I try to
show the pref pane of growl - because I can't tell from my app if the
notification is enabled or not anymore - and on top of that I can only
do this for growl < 1.3.

From your point of view I might be trying to go too far, but the fact
is you give the user a centralized way to enable / disable
notifications in growl preferences. It's global, and adding
independent logic in the app to do the same thing *on top of* the
growl preferences is just plain wrong.

Like I said the first time, ideally the app should be aware of the
growl preferences. At least there should be reliable ways to figure
out if growl is active and show up the growl preferences, regardless
of the growl version. All this should be in the SDK. This is not even
possible right now without extensive use of AppleScript. Sorry if I
come across a bit harsh but I really banged my head yesterday when I
started realizing all the issues introduced by the 1.3 version of
growl.

[Zeflash]

What if the user disable the notification in the growl pref? What
should my app show? In your case if he checks in the app, it'll show
that the notification is active. Yet it's not showing. Very confusing.

[Zeflash]

Actually you know what, instead of trying to figure out if it's
running or trying to show up the pref for all versions, the easiest
way would be to directly go to the App Support/Growl/Tickets folder
and read the notification status there.
It's definitely something the SDK should do for me, but at least I
don't have to do applescripts that way. I can show the notification
state in my app, and the mechanism to enable / disable the
notification from my app to growl is already in place.
I'll go this route, it'll be a better experience for the user than to
have 3 different menu items depending on many things.

I still hope you understood my motivations behind all my rambling ;)

On Dec 15, 6:28 am, Christopher Forsythe <ch...@growl.info> wrote:

[Zeflash]

Didn't work out either. Ended up having my code figure out the version
of growl by checking the presence of the Growl.prefpane in /Library/
PreferencePanes, in order to either open this prefpane if growl
version < 1.3, or just give a message telling the user to go to the
preferences by himself. Or enable / disable the notification if in
mist mode.

[Daniel Siemer]

Touching the Ticket file directly is definitely a no-no, those files
are not publicly stable, and might have fields or storage methods
added to it/removed from it in any given version. Going forward,
messing with the ticket file will also violate sandboxing containers.
As for isInstalled now always returning true, we are sorry this is a
pain, but unfortunately, it is the only thing that could be done.
Whether Growl is installed cannot be reliably detected across all
versions, particularly when you start throwing sandboxing in the mix.
isRunning should work for 1.2.x and older as well as 1.3+, I do not
know why that wouldn't be working for you (It simply uses
NSRunningApplication to find the app with the identifier
com.growl.growlhelperapp).

Opening the prefpane to your application will arrive in Growl.app 1.4,
and Growl.framework 1.4, via a URL scheme, which will have a method in
GrowlApplicationBridge to make it easy. We will also provide detection
for whether 1.4+ is installed, but we will not be removing the
deprecated status of isInstalled, since this will only work for 1.4+,
there will be a separate method for this.

For the time being, we do not have plans for providing developers more
direct access via the framework to mess with the on/off state (or
other settings) of their notifications. This could easily be abused,
say an app developer wants to show adds via growl, and the user want
to disable them, but the app keeps reenabling them without user
interaction, user gets mad at us. Yes, having on/off for all
notifications in both places can be confusing to users. Depending on
the application a sane set of defaults (which Mist will respect) and a
general notifications on/off switch might be enough.

[Rudy Richter]

beyond that statement, those tickets are actually going to be going
away and replaced by a CoreData backing store.

-rudy