That's done by gnome-shell, not Empathy. But yeah, I'd love such shortcut as well.

Renaming for clarity. This is relevant:

https://live.gnome.org/GnomeOS/Design/Whiteboards/KeyboardShortcuts

This would be a simple fix for somebody interested.

This is fixed in Shell 3.6.0, use Super+M

No. That does not expand and focus banners, but opens the tray.

Jon and Jimmac - any ideas for the keybinding to use here?

While we have plenty to throw around, I would be careful adding the <super>+? shortcut to everything. Maybe the keyboard driven response could involve the message tray, skipping the banner... <Super>+M, enter, respond...

But if you insist..

<Super>+b for banner
<Super>+x for being close ;)

(In reply to comment #7)
> While we have plenty to throw around, I would be careful adding the <super>+?
> shortcut to everything. Maybe the keyboard driven response could involve the
> message tray, skipping the banner... <Super>+M, enter, respond...

If the last received notification receives keyboard focus in the tray, that could make sense. That said, there is direct manipulation issue here - if people see a banner then that is the focus of their desire to interact.

> But if you insist..
> 
> <Super>+b for banner

Is banner a term that we expose users to? Maybe <Super>+r for "reply" or <Super>+n for notification? Alternatively, we could base it off the location of the notification, like <Super>+Shift+Down.

> <Super>+x for being close ;)

Or escape?

(In reply to comment #8)
> (In reply to comment #7)
> > While we have plenty to throw around, I would be careful adding the <super>+?
> > shortcut to everything. Maybe the keyboard driven response could involve the
> > message tray, skipping the banner... <Super>+M, enter, respond...
> 
> If the last received notification receives keyboard focus in the tray, that
> could make sense. That said, there is direct manipulation issue here - if
> people see a banner then that is the focus of their desire to interact.
> 
> > But if you insist..
> > 
> > <Super>+b for banner
> 
> Is banner a term that we expose users to?

No. I still call them the toaster notifications.

> Maybe <Super>+r for "reply" or
> <Super>+n for notification?

Too close to <Super>+m.

Alternatively, we could base it off the location > of the notification, like <Super>+Shift+Down.

Ow, my fingers.

My suggestion: make Ctrl+Alt+Tab into <Super>Tab, and make Notification the first item in the list. It has the quick "switching focus" appeal, and (well, I have a patch to add "Windows" to Ctrl+Alt+Tab somewhere, as it's awkward otherwise) you can switch back easily.

The only unfortunate item is that it might break workflow for accessibility users who may get used to the panel always being the first item. Have we studied accessibility users to know if they'll rely on Orca saying things to them, or will assume that Panel is the first item in the list?

> > <Super>+x for being close ;)
> 
> Or escape?

I meant keys being physically close to each other for fast response with one hand. But it's not good proposal, really.

No idea about possible a11y issues involved, but I like Jasper proposal

rethinking the problem a bit, cycling focus looks like another issue to me (which would be cool to have some shared logic with gtk+), so a direct shortcut like super+n works for me.

I don't see the proximity of the n key to m to be problematic (it could actually be a good thing). Super+n is still my preferred solution here.

If someone wants to try and fix this bug, please go for it. We can always argue about the exact keybinding later. :)

I'm on it.

Created attachment 228474 [details] [review]
messageTray: Add a notification focus keybinding

At the moment, only the mouse can be used to focus and answer a chat
notification.

This adds a new keybinding (defaults to <Super>+n) to focus and expand
the active notification.

Created attachment 228475 [details] [review]
messageTray: Close the notification on Escape

Now that the notifications can be focused with the keyboard, it's
important we can close the active one also this way.

Review of attachment 228474 [details] [review]:

As you could probably tell, I was hoping that someone would write this patch a lot quicker, given that it's not that hard.

But thanks!

Review of attachment 228475 [details] [review]:

::: js/ui/messageTray.js
@@ +1395,3 @@
                                                    x_expand: true,
                                                    layout_manager: new Clutter.BinLayout() });
+        this._notificationWidget.connect('key-press-event', Lang.bind(this, this._onNotificationKeyPress));

This should probably be key-release. I've always found doing something on an immediate key press to be a little hasty.

(In reply to comment #17)
> As you could probably tell, I was hoping that someone would write this patch a
> lot quicker, given that it's not that hard.
> 
> But thanks!

Sorry to take the easy ones, I'm waiting for input on more complex ones (657315 and 664204 mainly, 687583 possibly).

(In reply to comment #18)
> ::: js/ui/messageTray.js
> @@ +1395,3 @@
>                                                     x_expand: true,
>                                                     layout_manager: new
> Clutter.BinLayout() });
> +        this._notificationWidget.connect('key-press-event', Lang.bind(this,
> this._onNotificationKeyPress));
> 
> This should probably be key-release. I've always found doing something on an
> immediate key press to be a little hasty.

Well I wanted to ask the policy regarding this on #gnome-shell, because usually, keybindings without combination or modifier are good candidates for key press, especially enter/escape. This really feels a lot more reactive/faster for anyone (well, you win the few ms from releasing the key  for real :p).

I suppose this only works for extremely frequent and fast and non-dangerous actions (I would not do it for the overview for instance).

On a side note, sending a chat message is already on press, so you get the enter/escape duo on press.

You really want it on key release?

Created attachment 228497 [details] [review]
messageTray: Close the notification on Escape

Now that the notifications can be focused with the keyboard, it's
important we can close the active one also this way.

(In reply to comment #19)
> You really want it on key release?

This could just be habit, but a thing I do is press the escape key down when I'm almost finished reading, and then release it when the notification to go away.

Designers are free to override, but let's do key release for now.

Review of attachment 228497 [details] [review]:

minor nit, otherwise looks fine

::: js/ui/messageTray.js
@@ +1601,3 @@
     },
 
+    _onNotificationKeyPress: function(actor, event) {

onNotificationKeyRelease

Attachment 228474 [details] pushed as 7dc2355 - messageTray: Add a notification focus keybinding
Attachment 228497 [details] pushed as f30dcad - messageTray: Close the notification on Escape

Seems that this is fixed. Thanks for your work, Stéphane.