On 26 Oct 2010, at 04:35, Peter Hosey wrote:
> On Oct 25, 2010, at 19:47:09, Leandro de Oliveira wrote:
>> I'm thinking of just a library that is able to draw notifications without
>> much customization, no skin support, no application registration, just
>> enough for dropbox to show information that it wants. The user would be able
>> to download Growl as it's today to customize dropbox notifications if he
>> wants.
>
> Yes. This is exactly what has been proposed before.
>
>>> We now see anything that makes it harder for users to turn off or remove
>>> Growl (or Growl functionality) as an invitation to even more angry email.
>> I think Growl is supposed to implement something that Mac OS [X] does not by
>> itself but is useful to users, if so, then Growl functionality would not be
>> something that caused angry emails. End users would have to make some effort
>> (look in the dropbox forums for example) to know that the app uses Growl and
>> that he can customize notifications if he wants to and the blame for not
>> being able to turn off notifications would be put on dropbox since now it's
>> the one drawing notifications because Growl is not even installed, and
>> that's the right thing to do because Growl cannot and shouldn't make the
>> decision about showing or not notifications on behalf of dropbox. Makes
>> sense?
>
> Yeah.
>
> There are still a couple of problems with this, mainly in the area of
> workload.
>
> First, we'd have to implement it. Splitting out a mini-Growl into a framework
> that preferably could be embedded in multiple applications without them
> stepping on each others' notifications on the screen (so they'd have to
> co-ordinate positioning in a distributed fashion) is non-trivial.
>
> Then, once it's implemented and in use, it would complicate the
> troubleshooting. If we get a user who's angry about notification bubbles they
> can't seem to turn off, we have to figure out whether it's Dropbox (or
> whatever) having installed/persistently re-installing Growl *or* Dropbox (or
> whatever) displaying its own self-hosted Growl notifications.
>
> Conversely, it's quite possible that some users would come to believe that
> Growl is installed on their system when it's really an application displaying
> the notifications itself using its embedded Growl Lite. As I mentioned, this
> would get us more angry email—something along the lines of “How can I be
> seeing Growl notifications if you claim I don't have Growl installed?!”, only
> with more swearing in it.
>
> The simplest way, for us and for users, is for us to keep doing what we're
> doing: Maintain Growl as a stand-alone product that serves as a central
> notification-display facility when installed and is unavailable when not.
What if you didn’t have to maintain it separately? What if this was the
standard Growl framework functionality?
I think the main problem (and reason for the bundling) for apps using Growl is
that if there is no Growl, there are no notifications. So if an app relies on
its notifications and wants to use Growl it has to either: write its own
subsidiary notification system in case Growl isn’t installed, or make damn well
sure Growl is installed.
Is there some way the framework can maybe contain GrowlHelperApp and do
something like this on post:
Is Growl prefpane installed (to catch when Growl has been turned off)?
-Yes: post notification
- No: Is GHA running?
- Yes: post notification
- No: start GHA (bundled in framework)
This would rely on GHA being able to run independently of the Growl prefpane,
so the minimal set of basic notification style etc. would have to be built in
to that.
If the Growl prefpane is installed, then GHA could read its prefs from there,
if not then it falls back to basic defaults.
Main problem I can see is different versions of the framework would have
different GHAs, so this would make life complicated in terms of needing to
maintain backwards compatibility (although I’m guessing this is currently also
the case) and perhaps there would need to be some way if another app had a
framework with a more recent version of GHA to kill off the older one and start
the newer one.
But, since all apps essentially have their own copy of GHA, they are all able
to post notifications regardless of whether Growl.prefpane is installed. Since
they all check to see if an instance of GHA is already running before each
post, they all share that GHA while it is running, so the display co-ordination
and stuff works like it always has. Also, if the app containing the running GHA
quits, next time another app posts, it runs its GHA. And finally (most
importantly) I can’t think of a way this breaks any current installation of
Growl…
Correct me if I’m wrong ;)
--
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.
