"pete boardman" wrote:
> On 3 Feb 2006, at 20:59, John A.M. Darnell wrote:
>
>> Okay, after the ringing endorsement from Gary, I'm ready to look
>> closer
>> into it. Can someone share a web address?
>
> http://growl.info/downloads.php
First, thanks for fixing the subject line, John. I noticed that only after
I'd sent my post.
Secondly, as a "very quick" overview of the one area that seems to stump
some folks about implementing Growl, I'll share a basic understanding of the
principle of "registering notifications" -- in case it would be useful to
others, not that you will need it.
In some smaller groups during a November work session, this area was the
first initial confusion that emerged. Admittedly, I also initially
_thought_ Growl was more complicated than it is, because of the early
documentation. This is better now, I think, as Growl has grown, but I'll
share anyway.
Overview
1. Growl is a shared preference pane. Many applications (and scripts) can
use the Growl services.
2. Therefore, in order to allow the user ALL control over which apps (or
scripts) are allowed to post notifications, applications and scripts must
"register" their intent to post (this is "registering the application") and
must also register each notification they wish to possibly post.
3. Registering an application (or script) in Growls pref pane requires the
user to affirm the "authority" to post notifications. In practice, your
script (or app) will "register" and then the user must verify or allow it.
This is a one-time deal, and the user can turn off notifications for your
app/script at some later time, of course. [It is even possible to have the
registration process throw a standard dialog which says something like
"FontManager wants to register notifications with Growl. Allow this
application to post notices?" (I made up the text, but you get the point.)
4. The Growl preference pane allows "granular permission rules", so a user
may suppress all, or only one or more, of your registered notifications.
5. Growl notifications are not interactive in the sense of "dialogs", with
buttons. (Though they can be made into "click to dismiss" notices.)
In Practice
The "registering" of the script/app can be scripted (waiting for the user to
"allow" your script access to Growl, or even displaying a dialog asking the
user if it's okay. FontManager does this when its preference item to use
Growl is checked the first time.)
The "registering" of the individual notifications (broad types) can be
scripted. If your app/script is allowed full access, then no user
interaction is needed for each individual notification.
From AppleScript, only 4 pieces of information are needed to register an
application/script (and its individual notifications).
For example, here is a call to my own Growl registration handler (one line):
growlregister("Gary Test", {"notice001", "notice002", "notice003"},
{"notice001"}, "Smile")
The first item, "Gary Test", is the name that I've chosen for my script to
"go by" in the Growl pane.
The next item is a list of the notifications I will (or may) send. The names
can be anything. These have no bearing on the specific case-by-case content,
but naming them stops collisions from the multi-app, multi-notice design of
Growl. (It also helps me, the programmer, I think, to be more structured in
my planning process.)
The next item is the default notification to post, if I do not specify when
I actually post a notification.
The final item is the default application name whose icon I would like
displayed in the Growl notification, unless I specify a different one for a
specific notification.
Now, I've caused an entry to appear in the list, in the System Preference
Pane for Growl. The user can find this entry listed as "Gary Test". They
can disable everything identified as coming from "Gary Test", or they can
disable one or more from the list I registered.
As for posting a notification, again only a bit of information is needed.
Here is an call to my own Growl notification handler (again, one line):
growlnotify("goodbye gary", "Another test notice.", "Gary Test",
"notice003", "Microsoft Entourage")
Here, I only need to pass the Title text, the actual notification message,
the name of the application (script) as I registered it, the identifier of
the notification (again, fairly random, as I've named it), and then finally
the application icon I'd like, unless I'd like the default I used before.
So, the actual scripted usage of Growl is very simple (I've simplified life
with some handlers). It's the _description_ of the set-up that can seem
overly complicated, rather than any actual set-up.
Reiterating what Pete Boardman said, once Growl is installed then it is
accessible in many ways, from many apps/utils/scripting languages.
Two Handlers which might be useful...
(Note the line-wrap. Also note the 'tell' target, which is GrowlHelperApp.)
-- HANDLER: growlRegister
--
-- a, application name (the string of _your_ app's name);
-- n, notification names (list of strings of all of the notification names
you intend to send with your registered app);
-- dn, the default notification name if not specified;
-- i, icon of which application to use for your notifications (default)
on growlRegister(a, n, dn, i)
try
tell application "GrowlHelperApp" to register as application (a) all
notifications (n) default notifications (dn) icon of application (i)
return true
on error errMsg_ number errnum_
error errMsg_ number errnum_ from "growlRegister()"
end try
end growlregister
-- HANDLER: growlNotify
--
-- s, title string;
-- d, description string;
-- a, application name (as previously registered);
-- n, notification name (as previously registered);
-- i, icon of which application
on growlNotify(s, d, a, n, i)
try
tell application "GrowlHelperApp" to notify title (s) description
(d) application name (a) with name (n) icon of application (i)
return true
on error errMsg_ number errNum_
error errMsg_ number errNum_ from "growlNotify()"
end try
end growlnotify
These are very basic, but could get you up and running right away, until you
tweak your own approach.
HTH others.
--
Gary
|
