GNOME Bugzilla – Bug 645932
Hard to accept incoming calls and file transfer
Last modified: 2011-04-01 22:06:10 UTC
When you receive an incoming call or file transfer in Empathy you get a notification bubble which quickly disappear and then have to go to the bottom bar and click on Empathy's status icon to accept it. We should have a proper tray asking the user if he wants to accept/decline the request.
Maybe a duplicate of bug 645753 (or can be fixed as part of it)
I think it has been discussed that incoming phone calls should be "urgent" notifications while they are going on, so they are permanently onscreen until interacted with. Not sure if the same should apply to file transfers. h
I think the shell should handle those itself as the user can always disable notification bubbles in Empathy's preferences and so end up with an unusable system.
(In reply to comment #2) > I think it has been discussed that incoming phone calls should be "urgent" > notifications while they are going on, so they are permanently onscreen until > interacted with. Not sure if the same should apply to file transfers. What's the proper way to mark a notification as "urgent" btw?
notify_notification_set_urgency (notification, NOTIFY_URGENCY_CRITICAL);
I investigated this a bit and think I found the issue. Atm the Shell blacklists all the notifications coming from Empathy. In notificationDaemon.js we have: // Filter out notifications from Empathy, since we // handle that information from telepathyClient.js if (appName == 'Empathy') { But this is wrong as, atm, telepathyClient.js only handle 1-1 chats. We have two options here: A) improve telepathyClient.js to deal with other events (calls, file transfers, muc invitations, etc) B) only ignore 1-1 chat notifications and display the other one. A) is pretty big change at this point, so I'd suggest to do B) for 3.0 and progressively move to A) in the next cycle if we find the need to. B) can be done pretty easily: - Patch Empathy to set the urgent hint on most notifications. This will ensure that the notifications stays visible in the Shell and that actions buttons will be displayed. - Only filter 1-1 chat in Shell's notification daemon. One way to do that would be to add a 'x-empathy-event' hint or something that would describe the kind of event which raised the notification. So the Shell would just have to filter out the 'chat' ones.
I implemented B) is these 2 branches: http://git.collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/shell-notif-645932 http://git.collabora.co.uk/?p=user/cassidy/gnome-shell;a=shortlog;h=refs/heads/empathy-notif-645932
(In reply to comment #6) > - Only filter 1-1 chat in Shell's notification daemon. One way to do that > would be to add a 'x-empathy-event' hint or something that would describe the > kind of event which raised the notification. So the Shell would just have to > filter out the 'chat' ones. You don't need 'x-empathy-event', setting 'category' should be enough and compatible with other notification servers.
(In reply to comment #8) > (In reply to comment #6) > > - Only filter 1-1 chat in Shell's notification daemon. One way to do that > > would be to add a 'x-empathy-event' hint or something that would describe the > > kind of event which raised the notification. So the Shell would just have to > > filter out the 'chat' ones. > > You don't need 'x-empathy-event', setting 'category' should be enough and > compatible with other notification servers. Is there a list somewhere of well known keys? http://www.galago-project.org/specs/notification/0.9/x344.html doesn't mention any.
How about: http://people.gnome.org/~mccann/docs/notification-spec/notification- spec-latest.html#categories
The category list on http://www.galago-project.org/specs/notification/0.9/x211.html has 'im.received', which looks like a good match.
Cool, I updated both branches: http://git.collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/shell-notif-645932 http://git.collabora.co.uk/?p=user/cassidy/gnome-shell;a=shortlog;h=refs/heads/empathy-notif-645932 I just set the category for the chat notifications as that's the one we care here and the only one which reallty fits with the existing category anyway. We can add more categories later if needed.
Created attachment 184581 [details] [review] diff js/ui/notificationDaemon.js | 20 +++++++++++--------- 1 files changed, 11 insertions(+), 9 deletions(-)
Review of attachment 184581 [details] [review]: ::: js/ui/notificationDaemon.js @@ +193,3 @@ // handle that information from telepathyClient.js if (appName == 'Empathy') { + if (hints['category'] == 'im.received') { I think it's just slightly weird to access hints before we call Params.parse() on it, though fine here. My main concern with this patch is that it seems to break operation with Empathy without the Empathy patch applied. That could be considered a bit harsh. Would it make sense for Empathy to set hints for everything, so we could do if (hints['category'] != null && hints['category'] == 'im.received') ?
(In reply to comment #14) > My main concern with this patch is that it seems to break operation with > Empathy without the Empathy patch applied. That could be considered a bit > harsh. I think that's fine tbh. We should ask for grouped hard code freeze exception to the RT and be sure to merge both branches for 3.0. Gnome-shell testers shouldn't have troubles to update their Empathy and 'normal' users will have the whole GNOME 3.0 from their distributions. > Would it make sense for Empathy to set hints for everything, so we could do if > (hints['category'] != null && hints['category'] == 'im.received') ? We'll have to define our own x-empathy categories then. I don't think it's worth it.
Comment on attachment 184581 [details] [review] diff patch looks fine, although I'd probably do if (appName == 'Empathy' && hints['category'] == 'im.received') to avoid having to reindent everything else Owen said: > My main concern with this patch is that it seems to break operation with > Empathy without the Empathy patch applied. That could be considered a bit > harsh. "Break" meaning that the user would get double notifications, not that they'd get no notifications. And that can be fixed if the user turns off "Enable bubble notifications" in the Empathy preferences. There is also a second failure mode, which is that if the user has new Empathy and new gnome-shell, and has "Enable notifications when a contact comes online/goes offline" enabled in the Empathy prefs, then they will get double notification of (some) presence changes (because we won't be suppressing presence notifications from empathy any more).
(In reply to comment #16) > There is also a second failure mode, which is that if the user has new Empathy > and new gnome-shell, and has "Enable notifications when a contact comes > online/goes offline" enabled in the Empathy prefs, then they will get double > notification of (some) presence changes (because we won't be suppressing > presence notifications from empathy any more). Would it be appropriate to use 'presence.online'/'presence.offline' for those and filter them as well?
(In reply to comment #17) > (In reply to comment #16) > > There is also a second failure mode, which is that if the user has new Empathy > > and new gnome-shell, and has "Enable notifications when a contact comes > > online/goes offline" enabled in the Empathy prefs, then they will get double > > notification of (some) presence changes (because we won't be suppressing > > presence notifications from empathy any more). > > Would it be appropriate to use 'presence.online'/'presence.offline' for those > and filter them as well? I updated the empathy branch to set those categories as well; see http://git.collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/shell-notif-645932 (In reply to comment #16) > (From update of attachment 184581 [details] [review]) > patch looks fine, although I'd probably do > > if (appName == 'Empathy' && hints['category'] == 'im.received') > > to avoid having to reindent everything else done. http://git.collabora.co.uk/?p=user/cassidy/gnome-shell;a=shortlog;h=refs/heads/empathy-notif-645932 > There is also a second failure mode, which is that if the user has new Empathy > and new gnome-shell, and has "Enable notifications when a contact comes > online/goes offline" enabled in the Empathy prefs, then they will get double > notification of (some) presence changes (because we won't be suppressing > presence notifications from empathy any more). That's right. I see 3 options here: a) Add a 'x-empathy-contact' hint in presence notifications and check in notificationDaemon.js if we should discard the notification or not (by asking to the telepathyClient). That's s definitely the best solution but requiers non-trivial code changes, which is probably a bit late for 3.0. b) Ignore all presence notifications; keeping the current behaviour (atm all Empathy notifications are ignored). c) Display all presence notifications. I don't think it's that bad tbh, users can always disable presence notifications if he wants to. So I'd vote for b) and c); I don't really care which one, your call.
Created attachment 184672 [details] [review] notificationDaemon: only ignore 'chat' notifications from Empathy (#645932)
For the record, I requested a hard code freeze exception to merge the empathy patchs.
Comment on attachment 184672 [details] [review] notificationDaemon: only ignore 'chat' notifications from Empathy (#645932) Let's go for (b) (filter out both chat and presence notifications). I do think (c) would be good, but at this point I think it's best to not change the user experience any more than we have to. (Perhaps for 3.0.1 we could watch the relevant empathy gsettings key, and if empathy is configured to show presence notifications, then let them through and suppress our own.)
Created attachment 184857 [details] [review] notificationDaemon: only ignore 'chat' and 'presence' notifications from Empathy (#645932)
Here we go, this patch implements b).
Comment on attachment 184857 [details] [review] notificationDaemon: only ignore 'chat' and 'presence' notifications from Empathy (#645932) tested and this works fine. marking commit-after-freeze now. Needs ok from Owen and release-team to be commit-now.
So the patch filters out online and offline presence changes. What happens with other types of presence changes, such as busy or idle? Does Empathy notify on these if the user has presence notifications enabled? If so, this will cause some Empathy presence notifications to be showing up.
No, Empathy only notify online/offline presence changes so no problem here.
Approved by the RT. I merged the g-s and empathy branches. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.