waffle

Waffle is a weblog.
The author of Waffle, some guy in Sweden, also occasionally writes stmts.net.

Growl Changes Coming

Growl is about to go through some hard-hitting changes.

  • The next release, 1.3, will be Mac App Store only and 10.7+ only. (Frameworks will continue being backward compatible.) The Mac App Store will be the only supported binary venue. I assume building from source will still work.
  • Growl-WithInstaller.framework is going away because of misuse. And not primarily by small apps; Adobe, HP and Dropbox have all installed Growl without asking the user. Getting rid of Growl-WithInstaller is slightly curious because Growl-WithInstaller explicitly introduces itself and asks and so if everyone were using it there wouldn’t be a problem, but I guess they want to get away from the practice of bundling Growl with apps altogether, even well-behaved ones.
  • Growl is horrendously understaffed right now. You might think that Growl is an immovable object, an institution that will be around forever, but that depends on available hands to handle support, coding and infrastructure. They could really use the help.
  • All bundled and co-developed “hacks”, meaning the “official”, on-disk-image Growl-emitters that inject themselves except with a supported plugin API, will stop being supported, distributed and maintained, partly because of the infernal Mac App Store terms, but also because of the lack of resources.

I have voiced my opinions about this in private to a Growl team member loudly and insistently enough to make me unpopular. If you think you can constructively contribute in any way to help them achieve a better and alternate solution, now is a good time.

And if you are in one of the organizations that have been using Growl’s services while dirtying Growl’s reputation, I posit that the least this organization can do is consider what support it can lend. It is one of your dependencies, after all.

Comments

  1. “The next release, 1.3, will be Mac App Store only”

    Ugh.

    “The Mac App Store will be the only supported binary venue. I assume building from source will still work.”

    I generously nominate Jesper to produce an unsupported binary distro outside of Apple ID World, assuming such a thing is kosher.

    “Growl-WithInstaller.framework is going away because of misuse.”

    Agree or not in conclusion, I fully understand and can get behind their reasoning.

    “Growl is horrendously understaffed right now. You might think that Growl is an immovable object, an institution that will be around forever, but that depends on available hands to handle support, coding and infrastructure. They could really use the help.”

    I am always aware of the fragility of Growl and Perian, to name a couple of core OS X projects that seem held together by duct tape by a single guy working in an ice cave in Antarctica in his spare time between the eternal penguin hunts. And I’m always in awe of the developers.

    “All bundled and co-developed “hacks”, meaning the “official”, on-disk-image Growl-emitters that inject themselves except with a supported plugin API, will stop being supported, distributed and maintained, partly because of the infernal Mac App Store terms, but also because of the lack of resources.”

    Call me crazy, but I think that the resources would be somehow be cobbled together were it not for the execrable Mac App Store terms.

    But for the love of Buddha, someone’s got to find a way to make sure the hooks for growlnotify are still in the code, and that someone still makes a distro of growlnotify. It’s the only damn user-level hook into the product, and thus the only way for a non-developer to have the possibility of real custom-use scenarios.

    I rely on growlnotify to do stuff beyond the box with Growl. And folks could create AppleScript solutions to recreate versions of stuff like Mail and iTunes functionality, if only the growlnotify utility and Growl hooks still exist.

    Gotta have one user-level hook to let folks leverage the thing, IMHO…

    By Chucky · 2011.07.06 13:57

  2. Chucky: I can host the source code in perpetuity, but I can’t make sure I devote the necessary effort to keep it up to speed. What I’ve heard is that it’s way more time than you’d think.

    If it comes down to being able to rally a few people around this, their effort is better spent joining the existing Growl team and show up as the extra resources necessary to maintain what they’re considering dropping or not doing.

    Now, if the Growl team disagrees with that, forking becomes the most efficient alternative to retaining those features. My interpretation is not that they’re cutting down on these things out of glee but because it’s no longer sustainable.

    By Jesper · 2011.07.06 15:44

  3. @chucky: growlnotifyf is not going away. nor are GrowlTunes or HardwareGrowler. I suggest reading the linked to google groups post that Chris made.

    By rudy · 2011.07.06 16:28

  4. Lead Developer of Growl here. (And, FTR, I’m unaware of Jesper’s objections, outside of what he’s said in this post and his follow-up.)

    Chucky:

    I am always aware of the fragility of Growl and Perian, to name a couple of core OS X projects that seem held together by duct tape by a single guy working in an ice cave in Antarctica in his spare time between the eternal penguin hunts. And I’m always in awe of the developers.

    Growl itself is not fragile. It’s not the greatest of source code, but it’s not likely to break, either. Most of the Extras are also not especially fragile.

    GrowlMail is the one that keeps breaking, but it’s actually extremely robust: It’s been specifically fortified so that if it detects any change in Mail’s/Message.framework’s behavior, it deactivates itself as cleanly as it can. So far, this has never happened. It keeps breaking only because Apple keeps breaking it.

    GrowlSafari is quite fragile.

    “All bundled and co-developed “hacks”, meaning the “official”, on-disk-image Growl-emitters that inject themselves except with a supported plugin API, will stop being supported, distributed and maintained, partly because of the infernal Mac App Store terms, but also because of the lack of resources.” Call me crazy, but I think that the resources would be somehow be cobbled together were it not for the execrable Mac App Store terms.

    Nope. GrowlMail and GrowlSafari were in line for the guillotine even before we decided to go App Store.

    Apple breaks GrowlMail nearly every damn Mac OS X release. It’s easily as much work to maintain GrowlMail alone as it is to maintain all the rest of the products—Growl and all the other Extras together.

    GrowlSafari has not given us any grief yet, but, as I said, it’s fragile. I expect it to break with any future +1.0 Safari release, if not sooner.

    Both rely on undocumented internals, so we’re cutting both of them.

    But for the love of Buddha, someone’s got to find a way to make sure the hooks for growlnotify are still in the code, and that someone still makes a distro of growlnotify. It’s the only damn user-level hook into the product, and thus the only way for a non-developer to have the possibility of real custom-use scenarios. I rely on growlnotify to do stuff beyond the box with Growl. And folks could create AppleScript solutions to recreate versions of stuff like Mail and iTunes functionality, if only the growlnotify utility and Growl hooks still exist.

    The main argument against keeping growlnotify—and we haven’t decided anything about growlnotify!—is that there are already one or two GNTP-compatible command-line notifier tools. If they do everything growlnotify does, there’s not really a reason for us to write our own GNTP-compatible version of growlnotify. But we’ll cross that bridge when we come to it.

    We have no plans to remove AppleScript support from Growl.

    By Peter Hosey · 2011.07.06 18:38

  5. rudy: The same post that mentioned that if it doesn’t get through the App Store approval process, you’re not sure what to do with it (“we’ll evaluate our options there”)?

    By Jesper · 2011.07.06 20:04

  6. more likely than not it will remain a pkg installer like it currently is, and there will be a button in the configuration window of Growl that directs you to a page that lets you download and manually install it. MAS is big on “the user initiated”, so we can link to it, but ultimately the user has to install it themselves.

    By rudy · 2011.07.06 20:25

  7. Also, bear in mind we’re replacing Growl-WithInstaller with something better, so that we only maintain one framework and not two, and so that users/developers don’t have to install Growl to get a notification to fly onto screen. It’s not nearly as configurable, but it’s going to be a good middle ground we think. Less confusing for the users, easier to sell to management for software shops, etc etc.

    We also can’t have some dev accidentally using Growl-WI and then getting booted from the app store because of that.

    By Chris Forsythe · 2011.07.06 20:48

  8. rudy: If that’s the case, that’s comforting. “We’ll see what we end up doing” makes it seem like dropping it entirely is an option, and no one wants to see that happen. Of course it will be user initiated.

    Chris: They will still have to install Growl, just from the App Store.

    The second paragraph brings up a good point: there are tons of apps out there with Growl-WithInstaller today that you can’t possibly make go away. If this is a matter of “accidentally using it”, it’d have to be a previous version. In that case, there are plenty apps out there to trigger it. I am confused by this line of reasoning.

    By Jesper · 2011.07.06 22:51

  9. It’s not making them go away. Here’s the deal, the g-wi drop is because I’ve wanted it to go away and others have for a long time now. The Adobe and Dropbox (one didn’t use g-wi, the other used a modified version) debacle didn’t help to instill user confidence.

    We need to move to the mac app store to help with some validity. Apple will vet our products and help to assure to end users that Growl is very legit. It’s not our fault that HP driver software installs Growl without telling users, but it is our problem to deal with.

    As to those developers, they can continue to use the older framework if they really, really want to do it. However, there will be no further updates to it, and it won’t work with Growl 2.0. The problem is that the app store does not allow for software to install other software without confirmation. We do provide that dialogue, but if the app store changes rules we don’t want these apps to get booted due to that alone. So we’re providing a way to make things better, we’re making it so that we don’t have to maintain 2 frameworks, and honestly we’re improving the experience for the end user. This is being done by an application developer on our team who is very motivated to make the end user experience better for this all around.

    By Chris Forsythe · 2011.07.06 23:16

  10. Chris: Yes, but the installation doesn’t go away — “and so that users/developers don’t have to install Growl to get a notification to fly onto screen”.

    By Jesper · 2011.07.07 00:04

  11. I’d like to point out comment 4, which got stuck in waffle’s spam queue yesterday, by Peter Hosey, lead developer of Growl and friend of waffle. None of the comments between 5 and 10 have been informed by reading that comment.

    By Jesper · 2011.07.07 00:30

  12. Yes it does Jesper. For a notification to present itself a developer will only need to have Growl.framework. For a user to control it, they will need Growl.app.

    By Chris Forsythe · 2011.07.07 02:03

  13. Chris: That’s a big change, one I hadn’t teased out by reading the mailing list message. That should be in big letters somewhere.

    By Jesper · 2011.07.07 18:45

  14. It’ll be in big letters when it’s released. I said there was more, that email was already huge.

    By Chris Forsythe · 2011.07.07 19:26

  15. Fair enough, but at least don’t hit me over the head with it when you mention it offhand as if it was already public knowledge.

    By Jesper · 2011.07.08 00:31

Sorry, the comment form is closed at this time.