Do we keep GrowlMail?

[Christopher Forsythe]

At this point we've had GrowlMail receive more updates to it than any other Extra. It uses a private API, can theoretically break in really awful ways, and overall is a pita to support properly.

I'm at the point where, looking at it, the original goals of the Extras being examples is satisfied through the other Extras. I realize we have a sub-userbase surrounding GrowlMail, but I'm wondering if the pain of updating it every single release of OS X is worth it being continued.

Do any of the Developers actually use this plugin? I'm talking specifically about people who have commit access to Growl, or have contributed to Growl in the last 2 years. 

I'm really concerned that GrowlMail is eating up valuable time that could be used on Growl itself.

Chris

[Peter Hosey]

On Mar 22, 2011, at 14:20:08, Christopher Forsythe wrote:
> Do any of the Developers actually use this plugin? I'm talking specifically about people who have commit access to Growl, or have contributed to Growl in the last 2 years.

Yup.

[Josh]

I submitted a patch for it once. Hasn't made it into a release yet, so I'm not sure I count ;), but I certainly use it a lot.
Also, considering how often users refer to GrowlMail as Growl itself I expect they might consider it, as I do, one of the most useful applications of the growl notification system…
It would be a shame to see it go.

On a slight tangent, I was fiddling with Automator the other day and got to thinking if there wasn't a possible alternative to hacking at Mail's bundle stuff.
As far as I can tell, essentially all incoming emails end up as individual .emlx files inside various .mbox or similar directories inside ~/Library/Mail, right? I don't know a huge amount about them, but could Folder Actions do the trick? And I assume that if this is possible in Automator, there's probably some more elegant way that an application/service type thing could do a similar thing?

Josh

[Peter Hosey]

On Mar 23, 2011, at 02:01:16, Josh wrote:
> I submitted a patch for it once. Hasn't made it into a release yet, so I'm not sure I count ;)

Hmm? Got a link?

My general rule nowadays is that if it isn't in a ticket, it doesn't exist. If you haven't already submitted a ticket for it or attached it to an existing ticket (if one is relevant), you should do so and post the link here.

> Also, considering how often users refer to GrowlMail as Growl itself I expect they might consider it, as I do, one of the most useful applications of the growl notification system…

A very good point.

> I don't know a huge amount about them, but could Folder Actions do the trick?

Interesting idea.

The main drawback I can think of is that it'd be a total rewrite. The Preferences UI might remain mostly the same (mainly replacing the list of accounts and “only in inbox” checkbox with a list of inboxes), but all the guts would have to be written completely anew.

[Daniel Lee Siemer]

On Mar 22, 2011, at 5:20 PM, Christopher Forsythe wrote:

> Do any of the Developers actually use this plugin? I'm talking specifically about people who have commit access to Growl, or have contributed to Growl in the last 2 years.

I use it, but only because I started using it before I realized how annoying it is to keep up. Using private api's is something that Im not really against, except that whole "potentially break in horrible ways at any update" thing.

What does the applescript as a mail rule action option lack comparatively? I dont have a lot of time right this minute (on vacation!), but it looks like there should be a way to make a new rule in an installer script to make it easy for the user to get it there, and possibly we could make it so we initially setup the rules/scripts according to preferences set while in the installer (ie, rules for certain accounts, not spam email). Only thing I immediately see is that coalescing might or might not work.

Daniel Siemer
~heading out the door

[Peter Hosey]

On Mar 23, 2011, at 05:14:43, Daniel Lee Siemer wrote:
> What does the applescript as a mail rule action option lack comparatively? … Only thing I immediately see is that coalescing might or might not work.

That, and no click feedback. A Folder Action could coalesce on the pathname and respond to click by opening the .emlx file.

[Rudy Richter]

I say we come up with some way to monetize it if its eating up
"valuable time".

-rudy

[Peter Hosey]

On Mar 23, 2011, at 06:07:25, Rudy Richter wrote:
> I say we come up with some way to monetize it if its eating up "valuable time".

If we charge some sort of registration fee for it, that's just going to piss people off that much more when the software they paid for breaks after nearly every OS update.

[Christopher Forsythe]

I'd be ok with one of you doing that on your own, but you'd need to talk to the folks who have contributed to growlmail over the years.

I think the applescript mail rule folder action route is likely the best, but consider the fact that the mailbox format can change between major OS X releases.

If we can improve the applescript API to be up to par with the cocoa one, I really think that the mail rule is the best bet, and then having a configuration app (maybe built into the Growl prefpane?) would be the way to go.

Chris

--
You received this message because you are subscribed to the Google Groups "Growl Development" group.
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.

[i.aten...@gmail.com]

On 23 Mar 2011, at 10:57, Peter Hosey wrote:

> On Mar 23, 2011, at 02:01:16, Josh wrote:
>> I submitted a patch for it once. Hasn't made it into a release yet, so I'm not sure I count ;)
>
> Hmm? Got a link?
>
> My general rule nowadays is that if it isn't in a ticket, it doesn't exist. If you haven't already submitted a ticket for it or attached it to an existing ticket (if one is relevant), you should do so and post the link here.

oh, it’s quite old; already committed and everything, just in a branch somewhere i think ;)
http://code.google.com/p/growl/issues/detail?id=72

>
>> Also, considering how often users refer to GrowlMail as Growl itself I expect they might consider it, as I do, one of the most useful applications of the growl notification system…
>
> A very good point.
>
>> I don't know a huge amount about them, but could Folder Actions do the trick?
>
> Interesting idea.
>
> The main drawback I can think of is that it'd be a total rewrite. The Preferences UI might remain mostly the same (mainly replacing the list of accounts and “only in inbox” checkbox with a list of inboxes), but all the guts would have to be written completely anew.

Agreed, certainly a larger immediate developer time-sink. I was mostly interested to know if it was feasible or not.

The mail rules addition idea sounds much more sensible…

[Rudy Richter]

it wouldn't be the same as it is now, obviously if we monetize it we
are able to put out updates prior to OS releases with the new UUIDs
due to access to OS seeds, we'd additionally make the UUIDPatcher in a
polished form available to anyone that wants to be bleeding edge. It
wouldn't be how we've been handling it now where we're reacting long
after the updates are released.

-rudy

[Peter Hosey]

On Mar 23, 2011, at 18:12:24, Rudy Richter wrote:
> … we [would be] able to put out updates prior to OS releases with the new UUIDs due to access to OS seeds…

We wouldn't be able to release GrowlMail updates prior to the OS release, since that would be disclosing the UUIDs. Same reason we can't publish such changes in the public source code.

So the way that will go is:

1. Apple ships update
2. We have to apply the update and verify that they didn't change the UUIDs without putting out a new seed (didn't this happen at least once?)
3. We put out the GrowlMail update
4. Users update Mac OS X
5. Users launch Mail; find GrowlMail is broken
6. We still get email asking us whether there's an update.

And, for some users, #4 and #5 will be ahead of #3.

Ultimately, as long as Apple keep changing the UUIDs and requiring us to update GrowlMail every time, this problem will always exist.

There are only three ways I can see:

1. Kill off GrowlMail.
2. Get users to adopt some other mail client (Sparrow?) that doesn't suck and supports Growl. May overlap with #1.
3. Finish and ship the UUID patcher.

You mentioned #3 in your message, but that doesn't really have anything to do with whether we make GrowlMail commercial or not.

I still want to do #3. I'm not ready to give up on GrowlMail just yet, and making it commercial would not solve the existing problem and would create new ones (billing, registration/verification, who gets paid, etc.).

[Christopher Forsythe]

How done is the uuid patcher? 

[Peter Hosey]

On Mar 23, 2011, at 18:22:35, Peter Hosey wrote:
> … making it commercial would … create new [problems] (billing, registration/verification, who gets paid, etc.).

This made me think of a fourth solution:

4. Spin off GrowlMail to some other developer willing to maintain it as a commercial product, and wash our hands of it.

Not saying I want to do that yet, but it's an option if we get tired of dealing with GrowlMail at all.

[Peter Hosey]

On Mar 23, 2011, at 18:24:42, Christopher Forsythe wrote:
> How done is the uuid patcher?

80%. It looks right, but AFAIK, none of us have tested the current version yet. It also doesn't have any anti-casual-usage countermeasures yet.

[Peter Hosey]

On Mar 23, 2011, at 18:24:42, Christopher Forsythe wrote:

> How done is the uuid patcher?

While I've got it open, I'm going to work on it some more right now.

[Rudy Richter]

On Mar 23, 9:22 pm, Peter Hosey <p...@growl.info> wrote:
> On Mar 23, 2011, at 18:12:24, Rudy Richter wrote:
>
> > … we [would be] able to put out updates prior to OS releases with the new UUIDs due to access to OS seeds…
>
> We wouldn't be able to release GrowlMail updates prior to the OS release, since that would be disclosing the UUIDs. Same reason we can't publish such changes in the public source code.
>
> So the way that will go is:
>
> 1. Apple ships update
> 2. We have to apply the update and verify that they didn't change the UUIDs without putting out a new seed (didn't this happen at least once?)
> 3. We put out the GrowlMail update
> 4. Users update Mac OS X
> 5. Users launch Mail; find GrowlMail is broken
> 6. We still get email asking us whether there's an update.

that doesn't mean a means of dealing with that situation couldn't be
devised, such as a background process that we launchd that's always
running. send a ping back and forth between the mail bundle and the bg
process, if the bg process doesn't get a response do a version check
w/ the server to see if there's a new version and present a dialog to
the user letting them know there's an update. that combined with
having it download it sparkle-style and auto-install and relaunch
mail.app, i think its more than manageable.

the point i was trying to make with access to the OS seeds is that
we'd have the UUIDs before they release the update, giving us time to
test the update prior to release and being able to basically release
when they release, sure the users would end up getting the disabled
message, but they'd also get our "there's an update available"
message.

-rudy

[Christopher Forsythe]

If it were to go commercial, this is the most appealing to me. I don't want to deal with commercial shareware without making 25k to 50k a transaction, and GrowlMail isn't that kind of software. :)

Chris

[smajor]

If I may, from a user perspective:

- I've used GrowlMail off and on since Growl's inception. I stopped
using it, maybe a year ago, because of it's UUID issues - even though
I'm savvy enough to patch my own UUIDs for mail bundles.

- around that time I started using an AppleScript that was posted in
the old coccaforge forum. That as served me fairly well, but a
limitation is that Mail rules only work with messages arriving in the
InBox. Anyone (like me, now) that use Server Side mail sorting rules
are out of luck with this solution. I don't recall if this was an
issue with GrowlMail.

I find the folder actions option possibly the most useful if it can
monitor "all mailboxes" and not just the InBox. If the mbox format
changes once with every major update, that's a heck of a lot better
than 8, 9, 10 times with dot releases.

Would I pay for a dedicated GrowlMail app? Likely, no. If Growl was
rolled into something that offered more, like DockStar (Ecamm), I'd
buy it. As an owner of DockStar, maybe I'll ping them about Growl
support. Seems like a natural fit for that product.

2cents,
-smajor

[Christopher Forsythe]

Does Herald do enough to replace GrowlMail?

http://erikhinterbichler.com/software/herald/

Chris