Giles icon indicating copy to clipboard operation
Giles copied to clipboard

Growl Support Is Noisy & Annoying

Open NotMyself opened this issue 13 years ago • 11 comments

I wanted to create this issue to solicit some feedback. I have some ideas about making the Growl support a bit better. I heard some other folks had some comments and wanted to hear what you all had to say. Fire away.

A couple guys and I are planning on meeting up this saturday for a hack session in Tacoma, our plan is to work on Giles. Would love to come away from it with a better Growl implementation.

NotMyself avatar Feb 14 '12 19:02 NotMyself

Are you talking about making it less chatty, or changing the notifications?

idavis avatar Feb 14 '12 21:02 idavis

Both all suggestions are on the table.

NotMyself avatar Feb 14 '12 21:02 NotMyself

One thing is to try to determine which tests should be run. You can try to do convention such as changes to Foo will run Foo* tests, or use the TestCategory attribute to define a suite which will run by namespace or class.

idavis avatar Feb 15 '12 16:02 idavis

IMHO - determining which tests should be run is a separate concern, and I have some different ideas on this front.

The complaints that I've been hearing are more along the lines of "toast notifications are too distracting." I think a verbosity setting would be awesome. If you don't want to know about the build starting / finishing, you should be able to turn that off. Same with tests, say you only want to be notified when a test fails.

Others have asked for audio notifications, and if those are added, should be toggle-able.

codereflection avatar Feb 15 '12 21:02 codereflection

If you want less, what about only notifying on state change?

S=>BuildFailed
S=>BuildPassed
BuildFailed=>BuildPassed
BuildPassed=>BuildFailed
BuildPassed=>TestsFailed
BuildPassed=>TestsPassed
TestsFailed=>TestsPassed
TestsFailed=>BuildFailed
TestsPassed=>BuildFailed
TestsPassed=>TestsFailed

idavis avatar Feb 15 '12 21:02 idavis

That's a pretty good idea, and relatively simple to implement. What do you think Bobby?

codereflection avatar Feb 17 '12 16:02 codereflection

That's an interesting idea, I was actually going down the route of subscribing to events... so the rest runner and builder could fire events that listeners could subscribe to and the subscription could be configurable.

NotMyself avatar Feb 17 '12 23:02 NotMyself

I like that idea as well. Actually, they can both be combined. Growl support could be configured to only notify on state change, where as the console listener might report all events.

codereflection avatar Feb 17 '12 23:02 codereflection

OT: The other thing I would suggest is changed the good to go icon to green instead of orange/yellow check mark.

idavis avatar Feb 18 '12 13:02 idavis

The more I think about Ian's idea of notifying when state changes, the more I like it. I'd like to at least build in the capability to turn this mode on, as I think I would use it all the time.

codereflection avatar Feb 20 '12 17:02 codereflection

Jonathan and I started working on inverting user display interaction to be subscription/event based on Saturday. You should be able to see what we did on his fork of the project. He was interested in hacking on it some more today. He lives in Seattle. If you are interested I can get you his email address and you can get together today.

Sent from my iPhone

On Feb 20, 2012, at 9:17 AM, Jeff [email protected] wrote:

The more I think about Ian's idea of notifying when state changes, the more I like it. I'd like to at least build in the capability to turn this mode on, as I think I would use it all the time.


Reply to this email directly or view it on GitHub: https://github.com/codereflection/Giles/issues/16#issuecomment-4057703

NotMyself avatar Feb 20 '12 17:02 NotMyself