Lets kick growl_notify to the curb #194

scottdavis opened this Issue Dec 15, 2011 · 5 comments


None yet
3 participants

scottdavis commented Dec 15, 2011

Since ruby_gntp is far superior I plan on making growl_notify vaporware I can do a patch for this this weekend if you want


netzpirat commented Dec 15, 2011

I'd not say that ruby_gntp is far superior. It's just a different approach and diversity is a good thing. For myself, growl_notify never worked fine and so I brought ruby_gntp support to Guard, but for others it may be exactly the opposite. I'm not sure, but I think @thibaudgg and @rymai are using growl_notify.

It'd be sad to see growl_notify go. Comparing the download counts shows me that growl_notify has double the downloads than ruby_gntp, so it can't be that bad as you want to make us believe.

The upcoming Guard 0.9 release has a refactored notification module, so from a maintenance point there is no gain to remove growl_notify. Since the new notification configuration brings manifold configuration options for all the notification libraries, the opposite is true: it would be a loss not to have growl_notify with us.

If you don't like to spend more time into growl_notify development, then that's a good reason and just fine, but as long as it works I see no need to remove support for it. For example, the growl gem from TJ is unsupported for over 2 years, but it still works fine and people are using it.

Anyway, thank you for being part of the wonderful OSS community on GitHub and everything you shared with others.


scottdavis commented Dec 15, 2011

Well its not that I mind supporting it its just that I keep getting a flood of tickets because the dependent gem for growl_notify (rb-appscript) doesn't support forking and people using guard with spork etc get confused. I myself have moved to ruby_gntp which IMHO is much more robust since its using the new growl protocol.

I originally made growl_notify because the growl gem was using the growl cli tool growl_notify which the growl devs strongly advised against due to it doesn't come with a default growl install. In the new release of growl that functionality has been removed but now that they have built the gntp interface using growl_notify is A) slower and B) unnecessary.

The other option is I change the underlying dependency of growl_notify to use ruby_gntp so that it keeps the same simple configuration DSL that growl_notify has but wraps up the speed of ruby_gnpt because calling out to applescript for each message is just slow when your firing lots of events.


rymai commented Dec 15, 2011

FYI, I often get segfault errors when using spork + growl_notify (as reported in some issues here as well) so I guess I should give ruby_gntp a new try...

Anyways, I think @scottdavis has a point here... I'll try to use ruby_gntp tomorrow and will get back to you guys, but personally I'm not against removing growl_notify support.


scottdavis commented Dec 15, 2011

the segfault is caused by rb-appscript when spork forks the main process and rb-appscript has a temper-tantrum about shared memory

@netzpirat netzpirat closed this in 40e6225 Dec 19, 2011


netzpirat commented Dec 19, 2011

I have added some notes to growl_notify. If you want to remove the support for growl_notify completely, feel free to send a pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment