Growl 1.3 changes

1,264 views
Skip to first unread message

Christopher Forsythe

unread,
Jun 23, 2011, 5:37:05 PM6/23/11
to Growl Discuss, Growl Development, Growl Localizations, growl-n...@googlegroups.com
Folks,

We're working towards Growl 1.3. 10.7 is going to change things for us, and as such here are the changes coming down the pipe:

1) Growl is going to be put into the Mac App Store. There are multiple reasons for this:
   - This is the trend that we're seeing across the OS X community
   - This will make distribution much easier for us. One of the biggest complaints that I am seeing on Twitter is people complaining about updating. We do listen.
   - This allows us to get rid of the Disk Image entirely.
   - We can get rid of the PKG installer.
   - We no longer have to maintain Sparkle.
   - For most folks this will make Growl much easier to install and keep Growl up to date.
   - This move also leads to making Growl a much easier application to find.
   - There's more, but that's enough for this list.

2) Growl will become an application. This fits into the MAS rules more than anything else we're doing.

3) Anything which does not go into the Mac App Store will be retired. We already know that both GrowlMail and GrowlSafari no longer fit into this category. I fully expect that GrowlTunes and HardwareGrowler will continue in the Mac App Store. growlnotify should as well, but if it does not we'll evaluate our options there.

   Do not expect any further releases of GrowlMail or GrowlSafari. This is only in bold so that it's easier to see. This should not be unexpected to those who use GrowlMail already, since most of you know that it breaks with every Apple Mail update. That is simply not something we wish to keep up with. Going to the Mac App Store for distribution seals the fate of anything considered more or less a "hack".

4) Growl itself will become 10.7+. 10.6 and below will not be supported in 1.3. 10.7 does not cost a lot of money and we feel that in the long run that by supporting 10.6 and 10.7, it would be harder to push forward with Growl development.

   - Note: The framework will not be 10.7+, it will support previous frameworks so that Developers only need to include one framework.

5) Growl-WithInstaller.framework is going away.

6) We're changing the communication path to GNTP from NSDNC and DO. Applications which continue to use DO or NSDNC will get a line in the Console asking users to contact them to update their Growl framework. Since there is no other real way to communicate this change to Application Developers, we feel that this is the best way to inform them. If someone has a better idea here, please let us know.



All of these changes will take effect as soon as the mercurial repository is put back up. We have a technical difficulty there, but it should be resolved by Monday.

Also, keep in mind that we are looking for more Developers, and that these are not all of the changes coming.

Feel free to reply here or to talk to us on irc on freenode at #growl.

Chris

Christopher Forsythe

unread,
Jun 23, 2011, 5:40:03 PM6/23/11
to Growl Discuss, Growl Development, Growl Localizations, growl-n...@googlegroups.com
On Thu, Jun 23, 2011 at 4:37 PM, Christopher Forsythe <ch...@growl.info> wrote:
Folks,

We're working towards Growl 1.3. 10.7 is going to change things for us, and as such here are the changes coming down the pipe:

1) Growl is going to be put into the Mac App Store. There are multiple reasons for this:
   - This is the trend that we're seeing across the OS X community
   - This will make distribution much easier for us. One of the biggest complaints that I am seeing on Twitter is people complaining about updating. We do listen.
   - This allows us to get rid of the Disk Image entirely.
   - We can get rid of the PKG installer.
   - We no longer have to maintain Sparkle.
   - For most folks this will make Growl much easier to install and keep Growl up to date.
   - This move also leads to making Growl a much easier application to find.
   - There's more, but that's enough for this list.

2) Growl will become an application. This fits into the MAS rules more than anything else we're doing.

3) Anything which does not go into the Mac App Store will be retired. We already know that both GrowlMail and GrowlSafari no longer fit into this category. I fully expect that GrowlTunes and HardwareGrowler will continue in the Mac App Store. growlnotify should as well, but if it does not we'll evaluate our options there.

   Do not expect any further releases of GrowlMail or GrowlSafari. This is only in bold so that it's easier to see. This should not be unexpected to those who use GrowlMail already, since most of you know that it breaks with every Apple Mail update. That is simply not something we wish to keep up with. Going to the Mac App Store for distribution seals the fate of anything considered more or less a "hack".

4) Growl itself will become 10.7+. 10.6 and below will not be supported in 1.3. 10.7 does not cost a lot of money and we feel that in the long run that by supporting 10.6 and 10.7, it would be harder to push forward with Growl development.

   - Note: The framework will not be 10.7+, it will support previous frameworks so that Developers only need to include one framework.

One correction here. It will support previous OS X versions, not previous frameworks.

Chris

TJ Luoma

unread,
Jul 6, 2011, 5:51:02 PM7/6/11
to Growl Discuss

Am I correct in assuming that growlctl will cease to work?

If so, I would hope that a replacement would be considered. Being able
to check Growl's status, start, stop, and restart it in scripts is
very handy.

Christopher Forsythe

unread,
Jul 6, 2011, 6:51:50 PM7/6/11
to growld...@googlegroups.com
We're intending for growlnotify to continue working, so I don't see why growlctl would stop working either.

We'll have to figure it out though, it may not work immediately at the time of release.

Chris 

Peter Hosey

unread,
Jul 6, 2011, 7:01:23 PM7/6/11
to growld...@googlegroups.com
On Jul 6, 2011, at 15:51:50, Christopher Forsythe wrote:
> We're intending for growlnotify to continue working, so I don't see why growlctl would stop working either.

I'm pretty sure growlctl relied on the existence of a prefpane, so it will stop working when we replace the prefpane with an application.

Christopher Forsythe

unread,
Jul 6, 2011, 7:03:56 PM7/6/11
to growld...@googlegroups.com
But that doesn't mean we can't change it to make it work with the .app instead.
 
--
You received this message because you are subscribed to the Google Groups "Growl Discuss" group.
To post to this group, send email to growld...@googlegroups.com.
To unsubscribe from this group, send email to growldiscuss...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/growldiscuss?hl=en.


Peter Hosey

unread,
Jul 6, 2011, 7:05:11 PM7/6/11
to growld...@googlegroups.com
On Jul 6, 2011, at 16:03:56, Christopher Forsythe wrote:
> But that doesn't mean we can't change it to make it work with the .app instead.

So we're going to reincarnate it, then? We killed it off a long time ago, at your insistence.

(If so: Yay! I've always loved growlctl and continued to use it.)

Christopher Forsythe

unread,
Jul 6, 2011, 7:07:28 PM7/6/11
to growld...@googlegroups.com
I'm not opposed to having a set of small utilities that help scripters out. I'm just not ok with us spending time on things that we don't have time to spend.

If it's easy to make it work, I'm not opposed.

Chris 

Neal Horman

unread,
Jul 6, 2011, 10:30:17 PM7/6/11
to growld...@googlegroups.com, Growl Development, Growl Localizations, growl-n...@googlegroups.com
Will the new implementation still support the network udp protocol interface ?

Peter Hosey

unread,
Jul 6, 2011, 10:31:35 PM7/6/11
to growld...@googlegroups.com
On Jul 6, 2011, at 19:30:17, Neal Horman wrote:
> Will the new implementation still support the network udp protocol interface ?

Our plan is for Growl 1.3 to support both network protocols it always has supported, plus GNTP, and for Growl 2.0 to kill off all the old protocols—including the UDP one—leaving only GNTP.

Neal Horman

unread,
Jul 6, 2011, 10:52:21 PM7/6/11
to growld...@googlegroups.com, Growl Development, Growl Localizations, growl-n...@googlegroups.com

Christopher Forsythe

unread,
Jul 6, 2011, 11:24:21 PM7/6/11
to growld...@googlegroups.com
That's not correct. UDP goes in 1.3, GNTP and the local GAB method will be there. When 2.0 hits, GAB goes and GNTP is used full time for local. GNTP will also be available for local in 1.3.


UDP has been gone for a while now in the dev repo.


Chris 

Christopher Forsythe

unread,
Jul 6, 2011, 11:26:10 PM7/6/11
to growld...@googlegroups.com
On Wed, Jul 6, 2011 at 10:24 PM, Christopher Forsythe <ch...@growl.info> wrote:


On Wed, Jul 6, 2011 at 9:31 PM, Peter Hosey <p...@growl.info> wrote:
On Jul 6, 2011, at 19:30:17, Neal Horman wrote:
> Will the new implementation still support the network udp protocol interface ?

Our plan is for Growl 1.3 to support both network protocols it always has supported, plus GNTP, and for Growl 2.0 to kill off all the old protocols—including the UDP one—leaving only GNTP.



That's not correct. UDP goes in 1.3, GNTP and the local GAB method will be there. When 2.0 hits, GAB goes and GNTP is used full time for local. GNTP will also be available for local in 1.3.


UDP has been gone for a while now in the dev repo.



Also, keep in mind that because Peter had to stick around in the 1.2.x stuff, he was likely not aware of the networking change here.

Chris

ravedog

unread,
Jul 7, 2011, 3:00:09 AM7/7/11
to Growl Discuss


On Jun 23, 2:37 pm, Christopher Forsythe <ch...@growl.info> wrote:

> 3) Anything which does not go into the Mac App Store will be retired. We
> already know that both GrowlMail and GrowlSafari no longer fit into this
> category. I fully expect that GrowlTunes and HardwareGrowler will continue
> in the Mac App Store. growlnotify should as well, but if it does not we'll
> evaluate our options there.
>
>    *Do not expect any further releases of GrowlMail or GrowlSafari*. This is
> only in bold so that it's easier to see. This should not be unexpected to
> those who use GrowlMail already, since most of you know that it breaks with
> every Apple Mail update. That is simply not something we wish to keep up
> with. Going to the Mac App Store for distribution seals the fate of anything
> considered more or less a "hack".

> Chris

What is the logic behind killing GrowlMail and Growl Safari other than
they are plugins for Apple apps. DO you have to kill them to gain
entrance into the store?

Also, will it still be fully AppleScriptable and have the same
dictionary?

Peter Hosey

unread,
Jul 7, 2011, 3:03:47 AM7/7/11
to growld...@googlegroups.com
On Jul 7, 2011, at 00:00:09, ravedog wrote:
> What is the logic behind killing GrowlMail and Growl Safari other than they are plugins for Apple apps. DO you have to kill them to gain entrance into the store?

Growl could get into the store regardless of whether we kill GrowlMail and GrowlSafari.

GrowlMail has been a terrible support burden, as much work to maintain as all of our other products combined. GrowlSafari is fragile internally, so while it hasn't caused us many headaches *yet*, it's only a matter of time.

So, we're killing both of them. This will free up the time we'll need to make all the necessary changes to Growl and leave us plenty of time in the future to maintain all of our surviving products.

> Also, will it still be fully AppleScriptable and have the same dictionary?

That's the plan.

Dylan Ryan

unread,
Jul 7, 2011, 3:16:57 AM7/7/11
to growld...@googlegroups.com
Just my 2 cents. I also more or less only use growl because of growl-mail. Sure it's nice to get other notifications, but without growl-mail, I'd rather not have one more app running even if it is a very minor resource user. i.e. Growl Mail is the only thing that KEEPS me using Growl. Other things are nice but I can live without. 

What kind of work goes into maintaining growl-mail? I'd be willing to donate my time to keeping it up to date, but I am not the greatest coder in the world (though I learn quickly). Every time a new OS update comes out, I install it day 1, and I've always just manually added the new bundle-id to the old version of GrowlMail's .plist and it has always worked for me on both 32 and 64-bit intel machines, so (at least so far) no major changes have been *necessary* that I've seen. If it's just adding the new IDs and (possibly many) minor internal changes (and rebuilds), I can do that no problem (I have access to a 64-bit intel MBP that I always keep up-to-date, a 32-bit intel MBP that I can either keep up-to-date or lag a version if needed, and PPC machines on Tiger as well, so I can test on a fairly wide spectrum of hardware and software).

Can you give us more info on what the changes it typically requires are? If I think I can handle it, I'll take full responsibility for getting things done promptly and keeping it alive for as long as I can. (In all likelihood, I'll just be building my own versions from source if it dies anyway, so I may as well help the project out instead of being selfish about it).

I am less interested in handling Growl-Safari, as I personally do not use it much and given what you just said, it sounds beyond my ability. Though as long as it isn't a major headache, I can handle minor changes to it (that is, I am willing to keep it alive for as long as my skill allows me to, if people are interested).


Dylan


Christopher Forsythe

unread,
Jul 7, 2011, 3:55:04 AM7/7/11
to growld...@googlegroups.com
On Thu, Jul 7, 2011 at 2:16 AM, Dylan Ryan <dylan...@gmail.com> wrote:
Just my 2 cents. I also more or less only use growl because of growl-mail. Sure it's nice to get other notifications, but without growl-mail, I'd rather not have one more app running even if it is a very minor resource user. i.e. Growl Mail is the only thing that KEEPS me using Growl. Other things are nice but I can live without. 

GrowlMail source is freely available, you may maintain it on your own.
 

What kind of work goes into maintaining growl-mail? I'd be willing to donate my time to keeping it up to date, but I am not the greatest coder in the world (though I learn quickly). Every time a new OS update comes out, I install it day 1, and I've always just manually added the new bundle-id to the old version of GrowlMail's .plist and it has always worked for me on both 32 and 64-bit intel machines, so (at least so far) no major changes have been *necessary* that I've seen. If it's just adding the new IDs and (possibly many) minor internal changes (and rebuilds), I can do that no problem (I have access to a 64-bit intel MBP that I always keep up-to-date, a 32-bit intel MBP that I can either keep up-to-date or lag a version if needed, and PPC machines on Tiger as well, so I can test on a fairly wide spectrum of hardware and software).

Can you give us more info on what the changes it typically requires are?

Check the release notes and tickets, those are the best things to look at.
 
If I think I can handle it, I'll take full responsibility for getting things done promptly and keeping it alive for as long as I can. (In all likelihood, I'll just be building my own versions from source if it dies anyway, so I may as well help the project out instead of being selfish about it).


The problem is that then GrowlMail becomes the only thing we ship that is still a distraction. In four months say you don't want to do this anymore, then we have to kill it yet again.
 
I am less interested in handling Growl-Safari, as I personally do not use it much and given what you just said, it sounds beyond my ability. Though as long as it isn't a major headache, I can handle minor changes to it (that is, I am willing to keep it alive for as long as my skill allows me to, if people are interested).



I'd say take on what you like.

We haven't sent the official email about the details of GrowlMail being retired yet, please wait for that first.

Chris

Christopher Forsythe

unread,
Jul 7, 2011, 3:56:49 AM7/7/11
to growld...@googlegroups.com
On Thu, Jul 7, 2011 at 2:00 AM, ravedog <rav...@gmail.com> wrote:


On Jun 23, 2:37 pm, Christopher Forsythe <ch...@growl.info> wrote:

> 3) Anything which does not go into the Mac App Store will be retired. We
> already know that both GrowlMail and GrowlSafari no longer fit into this
> category. I fully expect that GrowlTunes and HardwareGrowler will continue
> in the Mac App Store. growlnotify should as well, but if it does not we'll
> evaluate our options there.
>
>    *Do not expect any further releases of GrowlMail or GrowlSafari*. This is
> only in bold so that it's easier to see. This should not be unexpected to
> those who use GrowlMail already, since most of you know that it breaks with
> every Apple Mail update. That is simply not something we wish to keep up
> with. Going to the Mac App Store for distribution seals the fate of anything
> considered more or less a "hack".

> Chris

What is the logic behind killing GrowlMail and Growl Safari other than
they are plugins for Apple apps.

They are distractions causing Growl updates to lag behind by dramatic amounts of time, which is no longer acceptable or maintainable imho.
 
DO you have to kill them to gain
entrance into the store?


For them, yes. For Growl, no.
 
Also, will it still be fully AppleScriptable and have the same
dictionary?


Applescriptable, yes. Same dictionary.. maybe? One of our devs was looking into the click handler stuff, so maybe it'll be more robust. We're not killing Applescript, where is this rumor coming from?

Chris

ravedog

unread,
Jul 7, 2011, 3:57:11 AM7/7/11
to Growl Discuss


On Jul 7, 12:55 am, Christopher Forsythe <ch...@growl.info> wrote:
> > long as it *isn't* a major headache, I can handle minor changes to it
> > (that is, I am willing to keep it alive for as long as my skill allows me
> > to, if people are interested).
>
> I'd say take on what you like.
>
> We haven't sent the official email about the details of GrowlMail being
> retired yet, please wait for that first.
>
> Chris
>
>
>
> > Dylan
>
> > On Jul 7, 2011, at 12:03 AM, Peter Hosey wrote:
>
> > On Jul 7, 2011, at 00:00:09, ravedog wrote:
>
> > What is the logic behind killing GrowlMail and Growl Safari other than they
> > are plugins for Apple apps. DO you have to kill them to gain entrance into
> > the store?
>
> > Growl could get into the store regardless of whether we kill GrowlMail and
> > GrowlSafari.
>
> > GrowlMail has been a terrible support burden, as much work to maintain as
> > all of our other products combined. GrowlSafari is fragile internally, so
> > while it hasn't caused us many headaches *yet*, it's only a matter of time.
>
> > So, we're killing both of them. This will free up the time we'll need to
> > make all the necessary changes to Growl and leave us plenty of time in the
> > future to maintain all of our surviving products.

makes sense. just sad. I can wrote Applescripts to do it I guess.
>
> > Also, will it still be fully AppleScriptable and have the same dictionary?
>
> > That's the plan.
>

Awesome on the AppleScript (thats how I use growl)...

I forgot to ask... will Prowl work?

ravedog

unread,
Jul 7, 2011, 3:58:35 AM7/7/11
to Growl Discuss
YOu know you can just write a mail rule using applescript and growl -
it would do exactly the same thing as the plug in.

Christopher Forsythe

unread,
Jul 7, 2011, 4:00:23 AM7/7/11
to growld...@googlegroups.com
There are some minor differences, mostly due to the fact that the applescript api lacks clickback support I believe.

Chris

Dylan Ryan

unread,
Jul 7, 2011, 4:36:35 AM7/7/11
to growld...@googlegroups.com
On Jul 7, 2011, at 12:55 AM, Christopher Forsythe wrote:



On Thu, Jul 7, 2011 at 2:16 AM, Dylan Ryan <dylan...@gmail.com> wrote:
Just my 2 cents. I also more or less only use growl because of growl-mail. Sure it's nice to get other notifications, but without growl-mail, I'd rather not have one more app running even if it is a very minor resource user. i.e. Growl Mail is the only thing that KEEPS me using Growl. Other things are nice but I can live without. 

GrowlMail source is freely available, you may maintain it on your own.

I know, but I'd rather keep it "official" for more people to be able to find. I could make my own and host it (probably on dropbox since that's the easiest), but very few people would find it. Though if I did and you could link to it, that'd work too. I just don't want to maintain it online if the majority of growl users have no easy way to find it. I'd maintain it for myself regardless since I use it, but doing testing for other than my configuration is something I'd only do if I know more than a handful of people can find it.

 

What kind of work goes into maintaining growl-mail? I'd be willing to donate my time to keeping it up to date, but I am not the greatest coder in the world (though I learn quickly). Every time a new OS update comes out, I install it day 1, and I've always just manually added the new bundle-id to the old version of GrowlMail's .plist and it has always worked for me on both 32 and 64-bit intel machines, so (at least so far) no major changes have been *necessary* that I've seen. If it's just adding the new IDs and (possibly many) minor internal changes (and rebuilds), I can do that no problem (I have access to a 64-bit intel MBP that I always keep up-to-date, a 32-bit intel MBP that I can either keep up-to-date or lag a version if needed, and PPC machines on Tiger as well, so I can test on a fairly wide spectrum of hardware and software).

Can you give us more info on what the changes it typically requires are?

Check the release notes and tickets, those are the best things to look at.
 

I did. For system updates forcing growlmail updates, all I see are scattered 1- or 2-line changes in the changelogs that look like they take all of 2 minutes (plus build/upload time) and could be trivially automated so that it's just a matter of running a "fixGrowlMail" script and having a bundle ready. Add in some (also easily automated) testing on a variety of systems, and I am not seeing anything that would take more than an hour tops per minor system update, with possibly more considerable changes for major system updates. Since you say that it is the most time-consuming part of maintenance, I am assuming there must be a lot more than this, but I am not seeing it with a cursory glance at the 'logs. It doesn't help that over half the links on the growlmail changelog go to a non-public repo (http://growl.info/hg/growl-development/) so I have to delete the -development from the URL to see them. 

Looking at the open growlmail tickets, they all look either minor or else things that I can certainly try my hand at. (I might start chipping away at them shortly, just to see if my expectations match reality)

Basically, from what I can see, the known required maintenance (at system updates) looks minimal, and for the most part, growlmail works now. So, I can certainly handle trivial maintenance duties, and can try to tackle other bugs. Of course, it's possible I'm being horribly naive about it, but the bare minimum job of keeping it working as well as it works now is something I can (and will) definitely do. 

If I think I can handle it, I'll take full responsibility for getting things done promptly and keeping it alive for as long as I can. (In all likelihood, I'll just be building my own versions from source if it dies anyway, so I may as well help the project out instead of being selfish about it).


The problem is that then GrowlMail becomes the only thing we ship that is still a distraction. In four months say you don't want to do this anymore, then we have to kill it yet again.

Not likely to be a problem. Barring any catastrophes, I'm willing to maintain it forever, if only because I use it and will want it fixed for me. Now, granted, I could get hit by a bus tomorrow, but other than that, I'll be keeping it running at least for myself for as long as I can anyway. If I can keep it going for everyone who uses it and keep it readily available/findable, I'm more than willing to do so.

 
I am less interested in handling Growl-Safari, as I personally do not use it much and given what you just said, it sounds beyond my ability. Though as long as it isn't a major headache, I can handle minor changes to it (that is, I am willing to keep it alive for as long as my skill allows me to, if people are interested).



I'd say take on what you like.

We haven't sent the official email about the details of GrowlMail being retired yet, please wait for that first.

Fair enough. Just putting it out there that I'm willing to take it on, along with all the support burden. 

Dylan Ryan

unread,
Jul 7, 2011, 4:39:43 AM7/7/11
to growld...@googlegroups.com
Exactly. With growlmail, clicking the notification opens the message (which lets you reply and marks it as read). With an applescript, clicking it just closes it. 

Christopher Forsythe

unread,
Jul 7, 2011, 5:04:22 AM7/7/11
to growld...@googlegroups.com
So in other words if we get clickback working then there's no need for GrowlMail? ;)

Chris

Christopher Forsythe

unread,
Jul 7, 2011, 5:06:52 AM7/7/11
to growld...@googlegroups.com
On Thu, Jul 7, 2011 at 3:36 AM, Dylan Ryan <dylan...@gmail.com> wrote:

On Jul 7, 2011, at 12:55 AM, Christopher Forsythe wrote:



On Thu, Jul 7, 2011 at 2:16 AM, Dylan Ryan <dylan...@gmail.com> wrote:
Just my 2 cents. I also more or less only use growl because of growl-mail. Sure it's nice to get other notifications, but without growl-mail, I'd rather not have one more app running even if it is a very minor resource user. i.e. Growl Mail is the only thing that KEEPS me using Growl. Other things are nice but I can live without. 

GrowlMail source is freely available, you may maintain it on your own.

I know, but I'd rather keep it "official" for more people to be able to find. I could make my own and host it (probably on dropbox since that's the easiest), but very few people would find it. Though if I did and you could link to it, that'd work too. I just don't want to maintain it online if the majority of growl users have no easy way to find it. I'd maintain it for myself regardless since I use it, but doing testing for other than my configuration is something I'd only do if I know more than a handful of people can find it.

 

What kind of work goes into maintaining growl-mail? I'd be willing to donate my time to keeping it up to date, but I am not the greatest coder in the world (though I learn quickly). Every time a new OS update comes out, I install it day 1, and I've always just manually added the new bundle-id to the old version of GrowlMail's .plist and it has always worked for me on both 32 and 64-bit intel machines, so (at least so far) no major changes have been *necessary* that I've seen. If it's just adding the new IDs and (possibly many) minor internal changes (and rebuilds), I can do that no problem (I have access to a 64-bit intel MBP that I always keep up-to-date, a 32-bit intel MBP that I can either keep up-to-date or lag a version if needed, and PPC machines on Tiger as well, so I can test on a fairly wide spectrum of hardware and software).

Can you give us more info on what the changes it typically requires are?

Check the release notes and tickets, those are the best things to look at.
 

I did. For system updates forcing growlmail updates, all I see are scattered 1- or 2-line changes in the changelogs that look like they take all of 2 minutes (plus build/upload time) and could be trivially automated so that it's just a matter of running a "fixGrowlMail" script and having a bundle ready. Add in some (also easily automated) testing on a variety of systems, and I am not seeing anything that would take more than an hour tops per minor system update, with possibly more considerable changes for major system updates.

There's a lot of problems with just mental state switching between Growl and GrowlMail. Part of the problem is that since this is all not really supported by Apple, we feel it's necessary to test the plugin for quite a while before providing an update. There's a certain responsibility there.
 
Since you say that it is the most time-consuming part of maintenance, I am assuming there must be a lot more than this, but I am not seeing it with a cursory glance at the 'logs. It doesn't help that over half the links on the growlmail changelog go to a non-public repo (http://growl.info/hg/growl-development/) so I have to delete the -development from the URL to see them. 


That's offline temporarily until 10.7 comes out to avoid nda violations.

Dylan Ryan

unread,
Jul 7, 2011, 5:12:21 AM7/7/11
to growld...@googlegroups.com
Assuming that everything else worked (getting the right picture for the sender, all the other right info, etc), yeah, that'd be enough for me. When I tested adding a simple applescript, it notified a good half-second faster than growlmail, too (though that might not apply once you have an applescript that gets all the same info as growlmail)

George

unread,
Jul 7, 2011, 5:46:57 AM7/7/11
to Growl Discuss
Could you not have growl in the app store and some plugins such as
GrowlMail etc. out of the app store much like Boom does? There is no
*legal* reason why that won't work plus you have a working example of
other software that already does that. Yes you will have to still
maintain a pkg installer for the out of store plugins and the process
might be a wee bit more complex that you like but my point is that you
don't have to dump the already existing code just because Apple won't
let you put it on the App Store.

Anyway, either way I'm and will be a huge fan and an active user so
thanks for all the work guys.

Dylan Ryan

unread,
Jul 7, 2011, 6:11:25 AM7/7/11
to growld...@googlegroups.com
On Jul 7, 2011, at 2:06 AM, Christopher Forsythe wrote:



On Thu, Jul 7, 2011 at 3:36 AM, Dylan Ryan <dylan...@gmail.com> wrote:

On Jul 7, 2011, at 12:55 AM, Christopher Forsythe wrote:



On Thu, Jul 7, 2011 at 2:16 AM, Dylan Ryan <dylan...@gmail.com> wrote:
Just my 2 cents. I also more or less only use growl because of growl-mail. Sure it's nice to get other notifications, but without growl-mail, I'd rather not have one more app running even if it is a very minor resource user. i.e. Growl Mail is the only thing that KEEPS me using Growl. Other things are nice but I can live without. 

GrowlMail source is freely available, you may maintain it on your own.

I know, but I'd rather keep it "official" for more people to be able to find. I could make my own and host it (probably on dropbox since that's the easiest), but very few people would find it. Though if I did and you could link to it, that'd work too. I just don't want to maintain it online if the majority of growl users have no easy way to find it. I'd maintain it for myself regardless since I use it, but doing testing for other than my configuration is something I'd only do if I know more than a handful of people can find it.

 

What kind of work goes into maintaining growl-mail? I'd be willing to donate my time to keeping it up to date, but I am not the greatest coder in the world (though I learn quickly). Every time a new OS update comes out, I install it day 1, and I've always just manually added the new bundle-id to the old version of GrowlMail's .plist and it has always worked for me on both 32 and 64-bit intel machines, so (at least so far) no major changes have been *necessary* that I've seen. If it's just adding the new IDs and (possibly many) minor internal changes (and rebuilds), I can do that no problem (I have access to a 64-bit intel MBP that I always keep up-to-date, a 32-bit intel MBP that I can either keep up-to-date or lag a version if needed, and PPC machines on Tiger as well, so I can test on a fairly wide spectrum of hardware and software).

Can you give us more info on what the changes it typically requires are?

Check the release notes and tickets, those are the best things to look at.
 

I did. For system updates forcing growlmail updates, all I see are scattered 1- or 2-line changes in the changelogs that look like they take all of 2 minutes (plus build/upload time) and could be trivially automated so that it's just a matter of running a "fixGrowlMail" script and having a bundle ready. Add in some (also easily automated) testing on a variety of systems, and I am not seeing anything that would take more than an hour tops per minor system update, with possibly more considerable changes for major system updates.

There's a lot of problems with just mental state switching between Growl and GrowlMail. Part of the problem is that since this is all not really supported by Apple, we feel it's necessary to test the plugin for quite a while before providing an update. There's a certain responsibility there.

I know, but I see it slightly differently. From my perspective, if there is a widespread problem with just adding the new UUIDs, odds are I'll notice it quickly after making a change. That is, extensive testing isn't necessary for a widespread problem, cursory testing will almost certainly find it. And if there is a highly specific problem, odds are no amount of testing I can do will find it because I probably don't have access to the right combination of hardware and software to trigger it anyway. That is, extensive testing isn't helpful because odds are I do not have the right equipment to trigger it, so why waste time trying to do the impossible? So rather than testing for a week knowing that odds are I won't find anything, to me it seems more logical to update the UUIDs, do a quick "does this work?" check on as much hardware as I can, then release it as a "potentially unstable" version an hour or two after a system update. Anyone who can't wait can use it and provide the large testing platform that I don't have access to, but the vast majority of people will likely find that it works because it passed the "works on my hardware so probably works in most places" test. This seems better than waiting a week or more to test, not finding anything, releasing a "this is stable" version, and having the same people that would have caught the problem in the "potentially unstable" version catch it anyway and report it. It cuts a week or more off the wait time for people willing to take a risk (makes people happy), means less problems on versions that are expected to be stable (makes people happy), etc. 

Granted, for general software, that is probably the worst possible method you could think of for pushing updates, but for such a small bundle that does just one thing (and does it well), it seems that it would be generally helpful. There aren't a lot of features to test, so a fairly basic "Does it work?" type check is close to exhaustive. Especially given the track record. As I said, as far as I have seen, I've never had a problem simply adding the UUIDs, so that has a track record of working (or I am lucky and have a blessed hardware/software combo that just happens to always work). Obviously, anything could change at any time, but I still think an unstable branch that updates fast and should work but might not, and a stable branch that almost always does work but takes time to update (think Chrome, etc) leads to getting updates out quicker, and if an unstable branch breaks for some people for a few days, well, that's why it's called unstable.

Hopefully that makes sense :) 

 
Since you say that it is the most time-consuming part of maintenance, I am assuming there must be a lot more than this, but I am not seeing it with a cursory glance at the 'logs. It doesn't help that over half the links on the growlmail changelog go to a non-public repo (http://growl.info/hg/growl-development/) so I have to delete the -development from the URL to see them. 


That's offline temporarily until 10.7 comes out to avoid nda violations.

Makes sense. But some of the links point to the (stable) hg and some to the dev. Would be better just to point them all to stable since I was able to delete -development and get to what looks like the right changesets in every case.

Richard Hamilton

unread,
Jul 7, 2011, 6:39:42 AM7/7/11
to growld...@googlegroups.com


On Thu, Jul 7, 2011 at 6:11 AM, Dylan Ryan <dylan...@gmail.com> wrote:
[...]
I know, but I see it slightly differently. From my perspective, if there is a widespread problem with just adding the new UUIDs, odds are I'll notice it quickly after making a change. That is, extensive testing isn't necessary for a widespread problem, cursory testing will almost certainly find it. And if there is a highly specific problem, odds are no amount of testing I can do will find it because I probably don't have access to the right combination of hardware and software to trigger it anyway. That is, extensive testing isn't helpful because odds are I do not have the right equipment to trigger it, so why waste time trying to do the impossible? So rather than testing for a week knowing that odds are I won't find anything, to me it seems more logical to update the UUIDs, do a quick "does this work?" check on as much hardware as I can, then release it as a "potentially unstable" version an hour or two after a system update. Anyone who can't wait can use it and provide the large testing platform that I don't have access to, but the vast majority of people will likely find that it works because it passed the "works on my hardware so probably works in most places" test. This seems better than waiting a week or more to test, not finding anything, releasing a "this is stable" version, and having the same people that would have caught the problem in the "potentially unstable" version catch it anyway and report it. It cuts a week or more off the wait time for people willing to take a risk (makes people happy), means less problems on versions that are expected to be stable (makes people happy), etc. 

Granted, for general software, that is probably the worst possible method you could think of for pushing updates, but for such a small bundle that does just one thing (and does it well), it seems that it would be generally helpful. There aren't a lot of features to test, so a fairly basic "Does it work?" type check is close to exhaustive. Especially given the track record. As I said, as far as I have seen, I've never had a problem simply adding the UUIDs, so that has a track record of working (or I am lucky and have a blessed hardware/software combo that just happens to always work). Obviously, anything could change at any time, but I still think an unstable branch that updates fast and should work but might not, and a stable branch that almost always does work but takes time to update (think Chrome, etc) leads to getting updates out quicker, and if an unstable branch breaks for some people for a few days, well, that's why it's called unstable.

Hopefully that makes sense :)

Does anyone know and feel free to comment whether, aside from UUIDs, the current GrowlMail works (at least to the quick "does this work" standard) with the 10.7 GM that's available to paid-up devs?   In other words, it's one thing if it probably has a couple years life left in it at a minimum.  But it it would need a lot more for 10.7 (and remember, Mail _is_ said to be changing, so I wouldn't care to bet on a guess either way), then maybe some alternative would be better.

Either way, clickback with AppleScript would be great, if possible.  And for those of us challenged by anything as "friendly" as AppleScript (give me C++ anytime over that!), some sample rules to approximate GrowlMail behavior corresponding to different preference settings would be a big help, particularly if having someone else keep GrowlMail alive turns out not to be as straightforward as adding UUIDs, running some quick checks, and repackaging it.

i.aten...@gmail.com

unread,
Jul 7, 2011, 10:14:49 AM7/7/11
to growld...@googlegroups.com

Attached is a start.
there are some reference applescripts in /Library/Scripts/Mail Scripts/Rule Actions for the mail bit
and current growl applescript docs here: http://growl.info/documentation/applescript-support.php

as for how to do stuff in applescript:
yes it can be frustrating at times.
good example; if one wanted to get rid of the <email address> bit at the end of the sender text in the above example, this is the best i’ve found so far: http://stackoverflow.com/questions/1716440/applescript-index-of-substring-in-string
:/


Josh

MailScript.scpt

Gary L. Gray

unread,
Jul 7, 2011, 10:18:52 AM7/7/11
to growld...@googlegroups.com
On Jul 7, 2011, at 10:14 AM, i.aten...@gmail.com wrote:

> Attached is a start.
> there are some reference applescripts in /Library/Scripts/Mail Scripts/Rule Actions for the mail bit
> and current growl applescript docs here: http://growl.info/documentation/applescript-support.php

This feels like a stupid question, but how do I implement it?

Gary

Peter Hosey

unread,
Jul 7, 2011, 10:50:13 AM7/7/11
to growld...@googlegroups.com
On Jul 7, 2011, at 01:36:35, Dylan Ryan wrote:
> It doesn't help that over half the links on the growlmail changelog go to a non-public repo (http://growl.info/hg/growl-development/) so I have to delete the -development from the URL to see them.

Oops. That was a temporary measure while those changesets weren't in the stable repo (/hg/growl/). I meant to come back and update them to go to stable, and have now done so. Thanks for pointing this out.

The website updates every 15 minutes, so the change will take effect at 8:00 AM PDT.

Peter Hosey

unread,
Jul 7, 2011, 10:52:58 AM7/7/11
to growld...@googlegroups.com
On Jul 7, 2011, at 02:46:57, George wrote:
> Could you not have growl in the app store and some plugins such as GrowlMail etc. out of the app store much like Boom does?

Growl and GrowlMail have nothing to do with each other besides a common set of developers. Killing GrowlMail and moving Growl to the App Store are unrelated actions.

> … my point is that you don't have to dump the already existing code just because Apple won't let you put it on the App Store.

The App Store has nothing to do with our killing GrowlMail. We were already planning to kill it before we decided to put Growl into the App Store.

We're killing GrowlMail because it's a terrible support burden. That's the only reason.

i.aten...@gmail.com

unread,
Jul 7, 2011, 10:54:39 AM7/7/11
to growld...@googlegroups.com

You mean have it run?
Mail -> Preferences -> Rules
add a new rule
set up which mails you want it to be run for (‘every message’ will run it on everything)
set the action to ‘run applescript’ and select the script, wherever you saved it

If you mean writing/editing scripts:
/Applications/Utilities/Applescript Editor.app

Gary L. Gray

unread,
Jul 7, 2011, 12:17:36 PM7/7/11
to growld...@googlegroups.com

The former. Thank you.

All the best,
Gary

Neal Horman

unread,
Jul 7, 2011, 12:29:37 PM7/7/11