There should be a hot key to close all notification windows on the screen. The user who made this request suggested ctrl-option-q, which I think would be an acceptable default, although it probably should be configurable.

Born out of [http://forums.cocoaforge.com/viewtopic.php?f=6&t=20811 a forum thread] where the same user primarily requested a hot key to close only the latest notification.

I don't think this should be in Growl. Growl is a gui app, what's wrong with option clicking the x button to close them all?

Option clicking the x button requires, two hands, a lot of steps, and a level of precision that reminds me of first person shooter video game.

Today, to get rid of all the notifications, a user has to find the option button and hold it down, grab the mouse, locate a notification, hover over the notification to cause the x to appear, and then finally click the x. I believe this is not a convenient user experience, and frankly a waste of time.

Imagine if a user could just do Ctrl-Option-Q (or any appropriate hotkey combination) and all the notifications would go away. This would result in a more convenient and faster user experience. Especially for power users of growl. More specifically, with just one hotkey combination a user would be able to get rid of all the notifications without ever having to touch the mouse or aim for an x...

I would have liked to see this issue get a higher priority, but as long as it gets implemented that doesn't matter.

I'd second this request. There are two kinds of people - mouse people and keyboard people, and while it's not a big deal to close notifications with mouse, having a shortcut is a missing feature that would help the keyboard people.

But OS X is a mouse based OS. The appeal of keyboard based operating system's/user interfaces is more for things like ratpoison (http://en.wikipedia.org/wiki/Ratpoison).

I do think that rouble brings up a point that might be worth investigating, whether we need to improve the ease of use when trying to click on the close button. However I don't have any problems with it in smoke so we'll need a bit more information as to how it's hard to use and requires the precision of a first person shooter.

While modern GUIs tend to be mouse-oriented, both Mac and Windows support all operations via keyboard. It's an accessibility issue, for disabled users in particular. So, OSes provide alternative for a good reason, and it's definitely a Good Thing. Since all OS functions are accessible via both mouse and keyboard, people just tend to use a mix which they individually prefer. I'd say, I'm 70% mouse / 30% keyboard. I think that both 100% mouse and 100% keyboard patterns are ineffective.

Now, I think a hotkey would be good for Growl, since notifications pop-up outside a window (or a monitor) where user works and has mouse cursor located. It would make a total sense to do it via a system-wide hotkey.

Imagine a user working on the leftmost of 3 monitors (I'm writing it on a 2-monitor system), and having to move mouse all the way to the rightmost periodically to dismiss Growl notifications.

I'd argue that developers and "superusers" make up a big large portion of Growl's user base. Further, these users are mostly keyboard centric. If I'm editing code, I want to be able to glance over and read my IM notifications and then make them go away. I don't want to take my hands off the keyboard. Nor do many other users in this very large segment.

I understand the gist of your argument but all this issue is asking for is the ability for some population of your users to -- if they chose to enable this feature -- to clear notifications without leaving the keyboard. If it is an opt-in feature, then your argument about some users accidentally clearing their notifications isn't an issue.

I wouldn't call myself a superuser, but I am certainly keyboard-oriented. Quicksilver and Growl are the first two apps I install on any Mac, and there's something weird about the fact that one is entirely keyboard-based and the other entirely mouse-based. If it's possible to make closing notifications with the keyboard an option, I'd greatly appreciate it.

Any feature we'd have implemented, is something we shouldn't be afraid to turn on by default.

I don't have a problem with having this if it makes sense for 80% of our users. That said, I don't think it makes sense for 80% of the users we have.

I'll leave this open for a while, in case someone comes up with a way to convince me of how this would work without violating 80/20. If by time we get to 2.0 and nobody has done that, we'll close this ticket and not fix it.

If the developers are keen to keep features wanted by minorities (<20% of users) out of the GUI, could this be implemented in the AppleScript dictionary instead?

In either case (hotkey or AppleScript verb), it think it'd be wise to omit the clearing of very recent notifications (e.g. within a last second) to avoid a race condition where the user tries to clear old notifications, and inadvertently clears a new one before seeing it. Presumably this race condition applies to option-clicking to clear, so it's not specific to keyboard control.

Would the developers be open to a patch, either extending the AppleScript dictionary, or the GUI?

If the 80/20 rule is important, would it make sense to make a informal survey on the growl mailing list to see whether users would want this directly in the GUI?

Surveying the list isn't really advantageous imho.

I don't think hidden features are that great of an idea. If we have something, we shouldn't hide it. Adium's push/pop feature for instance has been there for years, and barely any user knows about it. If we spend the time to work on something, we should show it in the GUI.

The discussion right now is whether or not something should even be implemented, not by whom. If it's later decided that this would be something to add in, then yes, a patch would be great. Right now we're just in planning stages with this ticket though, if that makes sense.

Regarding the race condition, perhaps you can make a new ticket for that? I think it's worth discussing further, but on its own.

I realize that the developers of the plugin might not use this feature, but, I am not sure less than 20% of users would use this.

No one can know for sure without polling the user community. However, just looking at this page, this defect has been starred by 6 people. I could not find any other open defect that had that many stars (I manually went through the critical and high defects, so I might have missed some).

Further, many different users (myself, dkroot1, hughes.matt, dgbeecher, mbhutton) have taken time to list out usecases in favor of this request. This page is probably one of the most active pages of all the open defects against growl.

If you type 'growl key...' in google, you will notice that 'growl keyboard shortcuts' is a google suggested choice. That means there are many users out there, looking for keyboard shortcuts for growl. Further if you look at google's ranking of the returned pages for that search, this page shows up high up there. This means that this request is what many people who searched for that query are looking for. Another page that shows up even higher in the search rankings is another request I put in (http://forums.cocoaforge.com/viewtopic.php?f=6&t=20734), that also had a lot of other users show interest.. but that request was shot down on some other grounds.

I guess, what I am saying is that we can't know for sure what percentage of users would use this feature, but what we can know is that it is popular out of the other open requests, and also popular enough to be shown in google suggest.

Personally, I think once this feature is added and advertised, over 90% of people would use it, because it would just be so convenient. It might even tickle the fancy of the developers ;-)

I appreciate that the growl developers have a vision, and want to stick to that vision, but I think you will lose out on growth opportunity for your product.

80/20 isn't about addressing issues that more than 20% would use. It's about addressing issues that 80% of people would use.

I'll review the rest of your comment later, just wanted to clarify that for you.

I want this

Alright, here's the deal. If someone can come up with a good mockup that works with the current mockups we have for improving the preferences (keep the mockups floating around on the development list in mind as well), and come up with a good key combo, then this might be worth doing.

That said, I'm having problems thinking of how this would all fit in.

I can suggest a key combo: Control-Command-W. It's unused by Mac OS X per Apple list (http://support.apple.com/kb/HT1343)

I'm not on development list, but if you refer me to some existing mockup(s), I can try to add this option there.

I need to get rid of the notifications without using my mouse once I read it. It will be the best feature but I don't know how to convince the author tho.

Moving this to later. Until someone mocks it up, it's going to sit in the Later milestone.

What exactly is there to mock up in a keymapping?

Mockup:

When keymapping is pressed, the same action is taken as if user clicked on Restart Growl.

I can add a mock up if you can send me a link to a sample mock up. However, as hughes.matt pointed out, I don't there is much to mock up.

@hughes.matt, hopefully we don't have to restart growl to achieve this.

@dkroot1, I like the suggstion of using Control-Command-W. It is unused and it can be executed with one hand.

Here is my mockup:

Mockup: When keymapping (Control-Command-W) is pressed, take the same action as if user clicked on Option key + X of any open notification.

Here are the two usecases I can think of.

Test case 1/Use case: 1. User comes back from lunch and finds 50 open sticky growl notifications 2. User presses Control-Command-W 3. All growl notifications disappear

Test case 2: 1. No open growl notifications 2. User presses Control-Command-W 3. Growl handles this gracefully and doesn't crash.

Open for comments.

tia, rouble

Presumably we need a mockup for section in the preference pane where the user can set or remove the keyboard shortcut.

The attached images show how this looks in the context of Jumpcut.app [1].

Use case "remove trigger": - User action: user clicks on the round "X" image next to the key combination - Expected behaviour: the keyboard trigger is deactivated

Use case "set trigger": - User action: user clicks in the white space in the key combination widget - Expected behaviour: the widget displays the text "type shortcut" - User action: user presses a combination of keys - Expected behaviour: the widget displays the key combination, and the key combination is activated

One things that's missing is where this should be placed in the preference pane. In order to contribute a mockup in context, we need to know where the current 2.0 mockups live. Is there a set of images in the forum somewhere? Or is there a development branch we could get read-only access to?

[1] http://jumpcut.sourceforge.net/

Look on the development list (not discuss list) for current mockups of the general tab. It'd need to live there, since this is general.

Assume there will be another checkbox added to notify if the currently active app is the one notifying. I'm not sure how to phrase that, but it'd work.

I had assumed we would use shortcut recorder, so you're on the right track here.

ctrl+cmd+w isn't a keymapping we'll choose by the way. It's too close to cmd+w for comfort in my opinion.

ctrl+cmd+w was an example. Making shortcut configurable would solve any issues that anybody has with the shortcut.

Making the shortcut configurable isn't a resolution for picking a sane default key combo.

Pick any that you deem sane or even leave the shortcut blank (disabled) by default. It would be all Good as long functionality is there.

IMHO

I want this so much that I've set up a QuicKeys mouse shortcut that works (albeit badly), just so that I don't have to hunt and peck.

Sign me up for the list that wants this feature. It's important.

Without a proper mockup which isn't just a screenshot of shortcut recorder, but rather is a mockup of how it would look in the current mockups floating around on the development list about how the general tab should look, this ticket will not be going any further.

There's a 'Pref Pane UI Re-design' discussion [1] on the Growl Development Google Group.

Are the mockups in that thread the right ones to use as a base?

[1] http://groups.google.com/group/growl-development/browse_frm/thread/1bf6dbb4b2e98a1a/e4bd74e9d0ec70a5

How about adding an Accessibility tab?

Do it!!

I'm a little dismayed by the developers posture on this matter! :-/

I'm a little dismayed that people aren't doing what I've asked them to do. Maybe you can Edmund.

mbh yes that seems to be one of them. There's plenty of others.

Folks I'm not opposed to this going in, I just have enough priorities for the other people that I'm relying on you, the people motivated to have this preference, to even just mock it up. I asked for a mockup on June 28th of last year. It's about a month away from June 28th of this year, and as of yet there is not a mockup like I've asked for. I can only conclude that none of you actually care that much about this, other than requesting it, except for perhaps mbhutton.

I need to see how this is going to look. I don't have any of the developers on the project saying they want to work on this, so I'm not going to force them if you guys aren't providing what we're asking for.

If there is not a mockup on this ticket by June 28th of 2011, then this ticket will likely be closed as WontFix on June 29th. I do not believe that having a ticket open for 1 year asking for our very talented user base to provide a bit of work back for something that a few people want is too much to ask, nor too hard to do. If you care about this feature making it in, provide a mockup, you have more than 1 month to do so.

Bah, changing this back, didn't mean to close it now.

Also, please note that we're changing how away notifications work. I don't think that this will even be an issue at all after 1.3.

I've attached a mock-up of a potential configuration UI for this feature, based on the UI in Jumpcut (MIT Licensed).

"Also, please note that we're changing how away notifications work. I don't think that this will even be an issue at all after 1.3."

I saw some notes about that -- collapsing lots of notifications into a single notification sounds great! From what I read, it still sounds like you'd need to reach for the mouse to clear notifications, so I expect this issue would be unaffected.

If the dev team is unhappy with the idea of cluttering the UI to please a small number of users, an alternative would be to add a 'clearnAllNotifications' action to Growl's AppleScript module.

An example invocation from AppleScript: " tell application "Growl" to clearnAllNotifications "

I'm suggesting this because I assume that the keyboard lovers / mouse haters interested in this issue are likely to already be using some form of launcher, like Quicksilver, Butler or FastScripts, and it's easy to configure these to run an AppleScript.

That's basically the same as the screenshots of Jumpcut you posted.

We all know what Shortcut Recorder looks like. What we're asking for is a mock-up of your proposed Growl UI for this feature. We want to see how you see it looking in the Growl preference pane.

Here's a possible location in the pref pane, without having to do many changes to the current one (i.e. putting it in 'General', without adding any other tabs, as there wouldn't be enough items in them to make it worth adding any).

I used the current xib file from hg as a base and just added two NSTextField items (a Label and a Text Field).

We'll take that under advisement, thank you.

Is this as much of an issue now that 1.3 has Rollup? i.e. is everyone still wanting this or did Rollup make this a non-issue?

There's no shortcut key to dismiss Rollup, so this is still an issue to me, since I still have to reach for my mouse to dismiss it when I get back to my computer and find notifications waiting for me. I'td actually be great to see full keyboard navigation in Rollup (i.e. Cmd-W to dismiss, ESC to dismiss all notifications for an app, arrow keys to browse through notifications, etc), but I guess that's out of the scope of this issue.

I found this bug while on the hunt for a way to dismiss the rollup with the keyboard. Is it scriptable? Can I set up a global hotkey with an Automator service Applescript to dismiss the rollup?

Answered my own question. The Growl docs specifically mention the Growl Control Suite available through Applescript for closing the rollup window (among other interesting things). So I can use that to create an Automator service that I can then bind to a keyboard shortcut to dismiss the rollup.

Alternately, I saw another suggestion elsewhere to limit the number of messages that appear in the rollup by having the rollup only collect "logged" messages and only keeping very few messages logged.

I'd really like to just be able to press escape to dismiss the rollup that is present when I return to my idle machine.

I also vote for just "Escape". Combined with the rollup being always on top, you're essentially saying, when you get back to your computer, "Okay I'm caught up, back to normal please."

Should be merged with http://code.google.com/p/growl/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20BlockedOn%20Summary%20Product&groupby=&sort=&id=323, correct?

No it shouldn't. These are two different things.

Is it not possible to ensure that the rollup is in focus when a user returns to his system? When I unlock my screen, the rollup appears foremost, but it is not in focus. If it was, I could simply hit Escape to dismiss it. To me, this is part of the main problem - to ease dismissing the "these two songs played while you stepped away for a minute".

This ticket is about closing all notifications with a hotkey. Not about closing the rollup window. They are two different things. Ticket 323 addresses the rollup window being closed with a hotkey.

Added in 6653:9841d263432f by Rudy. Closing.

Thanks for adding this - works like a charm!