Ability to close all notifications with a keyboard command

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by prhgr...@gmail.com on 27 Aug 2009 at 9:26

[GoogleCodeExporter]

Original comment by prhgr...@gmail.com on 27 Aug 2009 at 9:27

[GoogleCodeExporter]

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?

Original comment by chrisf.g...@gmail.com on 29 Aug 2009 at 2:34

[GoogleCodeExporter]

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.

Original comment by rou...@gmail.com on 21 Sep 2009 at 10:51

[GoogleCodeExporter]

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.

Original comment by dkro...@gmail.com on 6 Oct 2009 at 1:34

[GoogleCodeExporter]

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.

Original comment by chrisf.g...@gmail.com on 6 Dec 2009 at 4:53

[GoogleCodeExporter]

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.

Original comment by dkro...@gmail.com on 6 Dec 2009 at 5:55

[GoogleCodeExporter]

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.  

Original comment by hughes.m...@gmail.com on 5 Feb 2010 at 5:44

[GoogleCodeExporter]

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.

Original comment by dgbeec...@gmail.com on 16 Feb 2010 at 5:23

[GoogleCodeExporter]

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.

Original comment by chrisf.g...@gmail.com on 2 May 2010 at 11:16

• Added labels: Milestone-2.0

[GoogleCodeExporter]

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?

Original comment by mbhut...@gmail.com on 3 May 2010 at 4:35

[GoogleCodeExporter]

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.

Original comment by chrisf.g...@gmail.com on 3 May 2010 at 2:36

[GoogleCodeExporter]

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. 

Original comment by rou...@gmail.com on 3 May 2010 at 3:21

[GoogleCodeExporter]

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.

Original comment by chrisf.g...@gmail.com on 3 May 2010 at 3:55

[GoogleCodeExporter]

I want this

Original comment by scottsch...@gmail.com on 3 May 2010 at 5:47

[GoogleCodeExporter]

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.

Original comment by chrisf.g...@gmail.com on 28 Jun 2010 at 7:00

[GoogleCodeExporter]

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.

Original comment by dkro...@gmail.com on 19 Jul 2010 at 4:10

[GoogleCodeExporter]

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.

Original comment by alfred%s...@gtempaccount.com on 23 Jul 2010 at 8:35

[GoogleCodeExporter]

Original comment by chrisf.g...@gmail.com on 29 Jul 2010 at 4:30

• Added labels: Milestone-Later

[GoogleCodeExporter]

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

Original comment by chrisf.g...@gmail.com on 29 Jul 2010 at 4:57

[GoogleCodeExporter]

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.

Original comment by hughes.m...@gmail.com on 29 Jul 2010 at 5:21

[GoogleCodeExporter]

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

Original comment by rou...@gmail.com on 29 Jul 2010 at 6:03

[GoogleCodeExporter]

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/

Original comment by mbhut...@gmail.com on 29 Jul 2010 at 10:15

Attachments:

• add-hotkey.png
• show-or-remove-hotkey.png

[GoogleCodeExporter]

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.

Original comment by chrisf.g...@gmail.com on 29 Jul 2010 at 11:06

[GoogleCodeExporter]

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.

Original comment by chrisf.g...@gmail.com on 29 Jul 2010 at 11:07

[GoogleCodeExporter]

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

Original comment by dkro...@gmail.com on 30 Jul 2010 at 1:51

[GoogleCodeExporter]

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

Original comment by chrisf.g...@gmail.com on 30 Jul 2010 at 7:24

[GoogleCodeExporter]

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

Original comment by dkro...@gmail.com on 30 Jul 2010 at 10:10

[GoogleCodeExporter]

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.

Original comment by arvindsa...@gmail.com on 8 Sep 2010 at 10:08

[GoogleCodeExporter]

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

Original comment by lak...@gmail.com on 22 Sep 2010 at 4:08

[GoogleCodeExporter]

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.

Original comment by chrisf.g...@gmail.com on 9 Nov 2010 at 4:40

[GoogleCodeExporter]

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/1bf6dbb4b2e98
a1a/e4bd74e9d0ec70a5

Original comment by mbhut...@gmail.com on 9 Nov 2010 at 5:17

[GoogleCodeExporter]

How about adding an Accessibility tab?

Original comment by katyl...@gmail.com on 9 Nov 2010 at 5:17

[GoogleCodeExporter]

Do it!!  

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

Original comment by edmund.m...@gmail.com on 17 May 2011 at 9:28

[GoogleCodeExporter]

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.

Original comment by chrisf.g...@gmail.com on 17 May 2011 at 10:28

• Changed state: WontFix

[GoogleCodeExporter]

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

Original comment by chrisf.g...@gmail.com on 17 May 2011 at 10:28

• Changed state: WaitingOnUser

[GoogleCodeExporter]

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.

Original comment by chrisf.g...@gmail.com on 17 May 2011 at 10:29

[GoogleCodeExporter]

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.

Original comment by mbhut...@gmail.com on 21 Jun 2011 at 6:33

Attachments:

• Growl-Issue11-mock-up-1.png

[GoogleCodeExporter]

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*.

Original comment by p...@growl.info on 21 Jun 2011 at 6:41

[GoogleCodeExporter]

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).

Original comment by emanuele...@gmail.com on 21 Jun 2011 at 7:55

Attachments:

• Growl-Isue11-proposed-mockup-2.png

[GoogleCodeExporter]

We'll take that under advisement, thank you.

Original comment by ch...@growl.info on 28 Sep 2011 at 6:44

• Changed state: New

[GoogleCodeExporter]

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?

Original comment by ch...@growl.info on 11 Nov 2011 at 1:20

• Changed state: WaitingOnUser
• Added labels: Product-Growl

[GoogleCodeExporter]

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.

Original comment by emanuele...@gmail.com on 11 Nov 2011 at 7:23

[GoogleCodeExporter]

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?

Original comment by william....@gmail.com on 1 Feb 2012 at 7:25

[GoogleCodeExporter]

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.

Original comment by william....@gmail.com on 1 Feb 2012 at 7:28

[GoogleCodeExporter]

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.

Original comment by niel.lam...@gmail.com on 4 Feb 2012 at 1:57

[GoogleCodeExporter]

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."

Original comment by lee...@gmail.com on 18 Mar 2012 at 4:17

[GoogleCodeExporter]

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?

Original comment by lee...@gmail.com on 18 Mar 2012 at 4:17

[GoogleCodeExporter]

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

Original comment by ch...@growl.info on 18 Mar 2012 at 4:26

[GoogleCodeExporter]

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". 

Original comment by niel.lam...@gmail.com on 18 Mar 2012 at 7:38

[GoogleCodeExporter]

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.

Original comment by ch...@growl.info on 18 Mar 2012 at 9:06