Giles
Giles copied to clipboard
Growl Support Is Noisy & Annoying
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.
Are you talking about making it less chatty, or changing the notifications?
Both all suggestions are on the table.
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.
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.
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
That's a pretty good idea, and relatively simple to implement. What do you think Bobby?
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.
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.
OT: The other thing I would suggest is changed the good to go icon to green instead of orange/yellow check mark.
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.
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