Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

no way to turn growl off? #28

jackdempsey opened this Issue Jan 9, 2011 · 21 comments


None yet
4 participants

Is that right? I don't want to use it, but don't see a way to disable the UI.info call telling me to install it.


thibaudgg commented Jan 9, 2011

You can turn off Growl notification for Guard via the Growl prefpane in Mac OS X System Preferences.

Hi Thibaud,

So I have no choice but to install the growl gem and then disable it in prefs? Doesn't seem so user friendly to me. I'd be happy to look into adding support for disabling it if that'd be of interest to you.

update: hope that didn't come across as snarky, definitely no intent. Just honestly a bit surprised that it's not configurable. Do most people like growl notifications in this way? Anyway, again, happy to patch if wanted.


thibaudgg commented Jan 10, 2011

I agree with you, it's kind of lame we can't turning notification off.
A patch to add this option is very welcome, thanks for your feedback!


rymai commented Jan 10, 2011

Yep, it's welcome (and easy to implement)!

And yes, I like Growl notifications in this way! :)

ryanb commented Mar 30, 2011

Any update on this? I'd just like it if it ignored growl notification when the growl gem isn't installed. I personally don't like growl.

haven't had a chance yet. People agree that just ignore it if not installed, no config setting?

ryanb commented Mar 30, 2011

Just removing this line will solve it for me.

UI.info "Please install growl gem for Mac OS X notification support and add it to your Gemfile"

thibaudgg commented Mar 30, 2011

I'll will add an option to turn off notification when I'll get some time (maybe next week, I move to a new apartment this week-end)

@ghost ghost assigned thibaudgg Apr 10, 2011

@thibaudgg thibaudgg closed this in 42c2724 Apr 10, 2011

ryanb commented May 2, 2011

Not sure if this is fixed. I'm using Guard version 0.3.4 and am still seeing this message when using guard -n false.

Please install growl gem for Mac OS X notification support and add it to your Gemfile

thibaudgg commented May 2, 2011

That's weird, it's working for me. Please can you paste your Guardfile, maybe this message comes because a guard plugin calls Guard#growl_installed?.

@thibaudgg thibaudgg reopened this May 2, 2011

ryanb commented May 2, 2011

I'm using guard-rspec so maybe that's the problem? It's the default Guardfile generated by guard init rspec.


thibaudgg commented May 2, 2011

Ok, I'll investigate that more carefully. In the meantime you could use the :notification => false option of guard-rspec directly.

ryanb commented May 2, 2011

Cool, didn't realize there was a :notification option. Is that in the docs somewhere?

However this kind of thing is more of a personal preference, so I would rather not add it to a project which multiple people might use and contribute to. Others might want to use Growl.

Also the fact that any guard might call growl_installed? and have this as a side effect seems strange. Normally question mark methods don't have side effects and just return a boolean. What if that growl message was moved out of growl_installed? and just shown once at the start of guard? I wouldn't mind that so much because it's less noise.


rymai commented May 2, 2011

Yeah, the :notification option is under the "List of available options:" in the guard-rspec README.

I agree with you, the Guard's --notify option is more "personal" than the guard-rspec's :notification option.

And yes, I agree that at least we could show the "Please install growl gem for Mac OS X notification support and add it to your Gemfile" message only once at the start of Guard. But in any case, it seems that the --notify option is broken right now. :(

We'll have to investigate this, thanks for your input! ;)

ryanb commented May 4, 2011

I was thinking, since this is more of a personal preference thing, maybe it could be set through an environment variable? GUARD_NOTIFY=false That way it only applies to my environment and I don't have to set it in every project or pass the -n argument every time.


thibaudgg commented May 4, 2011

Right an environment variable (in addition to the -n argument) seems a good solution too. I'll add that for the next release.

@thibaudgg thibaudgg closed this in 2f94f9e May 6, 2011


thibaudgg commented May 6, 2011

It should be ok now. Please @ryanb can you test if it's ok for you before I made a new release. Thanks!

ryanb commented May 6, 2011

Hmm, I am getting this exception when running master branch of latest guard and guard-rspec.

/Users/rbates/.rvm/gems/ruby-1.9.2-p136@railscasts/bundler/gems/guard-5352528530f2/lib/guard/notifier.rb:27:in `notify': uninitialized constant Guard::Notifier::Growl (NameError)
    from /Users/rbates/.rvm/gems/ruby-1.9.2-p136@railscasts/bundler/gems/guard-rspec-5e2ea63bea75/lib/guard/rspec/formatter.rb:26:in `notify'
    from /Users/rbates/.rvm/gems/ruby-1.9.2-p136@railscasts/bundler/gems/guard-rspec-5e2ea63bea75/lib/guard/rspec/formatters/notification_rspec.rb:10:in `dump_summary'

rymai commented May 6, 2011

After setting ENV["GUARD_NOTIFY"] to false? (I haven't tested yet)

ryanb commented May 7, 2011

@rymai that exception was without passing anything. Actually when setting GUARD_NOTIFY I get a different exception.

/Users/rbates/.rvm/gems/ruby-1.9.2-p136@railscasts/gems/thor-0.14.6/lib/thor/core_ext/hash_with_indifferent_access.rb:26:in `[]=': can't modify frozen hash (RuntimeError)
    from /Users/rbates/.rvm/gems/ruby-1.9.2-p136@railscasts/gems/thor-0.14.6/lib/thor/core_ext/hash_with_indifferent_access.rb:26:in `[]='
    from /Users/rbates/.rvm/gems/ruby-1.9.2-p136@railscasts/bundler/gems/guard-5352528530f2/lib/guard.rb:19:in `setup'
    from /Users/rbates/.rvm/gems/ruby-1.9.2-p136@railscasts/bundler/gems/guard-5352528530f2/lib/guard.rb:26:in `start'
    from /Users/rbates/.rvm/gems/ruby-1.9.2-p136@railscasts/bundler/gems/guard-5352528530f2/lib/guard/cli.rb:15:in `start'
    from /Users/rbates/.rvm/gems/ruby-1.9.2-p136@railscasts/gems/thor-0.14.6/lib/thor/task.rb:22:in `run'
    from /Users/rbates/.rvm/gems/ruby-1.9.2-p136@railscasts/gems/thor-0.14.6/lib/thor/invocation.rb:118:in `invoke_task'
    from /Users/rbates/.rvm/gems/ruby-1.9.2-p136@railscasts/gems/thor-0.14.6/lib/thor.rb:263:in `dispatch'
    from /Users/rbates/.rvm/gems/ruby-1.9.2-p136@railscasts/gems/thor-0.14.6/lib/thor/base.rb:389:in `start'
    from /Users/rbates/.rvm/gems/ruby-1.9.2-p136@railscasts/bundler/gems/guard-5352528530f2/bin/guard:6:in `<top (required)>'
    from /Users/rbates/.rvm/gems/ruby-1.9.2-p136@railscasts/bin/guard:19:in `load'
    from /Users/rbates/.rvm/gems/ruby-1.9.2-p136@railscasts/bin/guard:19:in `<main>'

rymai commented May 7, 2011

Ok, I've fixed the last issue, but I'm afraid the first error you get is more tricky and we will maybe need an architecture change to fix it...

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