GNOME Bugzilla – Bug 631944
Don't use a status icon when using the Shell
Last modified: 2011-08-30 09:40:08 UTC
The GNOME notification servers (gnome-shell and notification-daemon >= 0.6.1) support notification persistence. This means that notification bubbles won't be transient and require backing with a status icon. We can drop use of status icons in these cases. http://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Compatibility
Created attachment 172161 [details] [review] Port to libnotify 0.6.1 The trivial part :)
Review of attachment 172161 [details] [review]: Thanks for the patch. Here is my review. ::: configure.ac @@ +39,3 @@ KEYRING_REQUIRED=2.26.0 LIBCANBERRA_GTK_REQUIRED=0.25 +LIBNOTIFY_REQUIRED=0.6.1 Strictly speaking, GNOME 2.91 still depends on libnotify 0.4.5, the dep should be bumped before we merge this. See http://live.gnome.org/TwoPointNinetyone/ExternalDependencies ::: src/empathy-status-icon.c @@ +207,3 @@ In this way the previous message will not be lost: the new message will appear below it, in the same notification */ + notification = notify_notification_new There is no equivalent to the _with_status_icon() variant?
In a new moduleset proposal we've been working on libnotify will be an internal required dependency and use git master. libnotify is now completely separated from status icons. We won't really be supporting status icons in GNOME 3.
And the harder part of fixing this bug is not addressed by this patch btw.
(In reply to comment #3) > In a new moduleset proposal we've been working on libnotify will be an internal > required dependency and use git master. We have for policy to not depend on unreleased component, so we'll merge this branch once libnotify 0.6.1 has been released and approved as a GNOME external dep. (In reply to comment #4) > And the harder part of fixing this bug is not addressed by this patch btw. Yeah sure :)
I updated your patch to use libnotify 0.7.0 and merged it. Thanks!
I started a branch: http://git.Collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/notif-persistence-631944 Could you test it and see how it goes? Note that atm, incoming events still have to be approved. Either using the contact list either using another Telepathy Approver. What should we do when the contact list is closed? We use to only hide the window but now we can't get it back from the status icon any more. Should we exit the contact list app? Atm we can't as it handle chats but that will be changed soon (bug #631946). If we do, we should think about how we deal with presence. Atm, Empathy set our presence to offline when exiting but we should stop doing that.
This is a comment in regard to the Empathy/GNOME Shell integration thread based on the discussion we had at the Boston Summit. from http://mail.gnome.org/archives/gnome-shell-list/2010-November/msg00026.html >> • hide the tray icon if the shell is running and no channels need approving; >Actually, I've been asked to always hide it if the shell is running: >https://bugzilla.gnome.org/show_bug.cgi?id=631944 >> • don't approve 1-1 Text channels if the shell is running; >What does that mean exactly ? Atm Empathy implements one Approver >(Client.Empathy.EventManager). When a channel needs to be approved, this >.event manager displays it: >- As a notification bubble (with buttons if the notification daemon >supports it) >- In the notification area >- In the contact list >So, if we disable the status icon (cf above) we'll still have the >notification bubbles and the contact list change. Is that ok ? >(Actually that's not true because the notification bubbles are currently >implemented with the status icon but that's an implementation detail, we >should be able to easily separate them). So the goal is to not have a tray icon at all, but have Empathy send us notifications about everything other than 1-1 Text channels. These notifications will result in an icon in the message tray that shows the last notification (or in the future all missed notifications) on click due to the notification persistence support in the Shell. The contact list should reflect all the requests other than 1-1 Text requests as well. The 1-1 Text requests should not be known to Empathy until the user has explicitly transferred to the Empathy chat window. Actually, I wonder what should happen with the channel handling and notifications about new text messages when the user a) has the Empathy chat window open and focused b) has the Empathy chat window open, but not focused c) has closed the Empathy chat window Does Empathy redispatch the channel back to the Shell at any point? How far is the current implementation on the branch from what I'm describing? I can test it when it's ready. Thanks!
I replied on the thread to keep as many people as possible in the loop.
[Removing GNOME3.0 target as decided in release-team meeting on March 03, 2011. This report has an "important" categorisation for GNOME3.0 but is not considered a hard blocker. For querying use the corresponding whiteboard entry added.]
> So the goal is to not have a tray icon at all Have we gotten any closer to this goal in the meantime ?
I turn out that having a confirmation in 2 place (ML and bug) isn't great so I'll copy paste my email. (In reply to comment #8) > This is a comment in regard to the Empathy/GNOME Shell integration thread based > on the discussion we had at the Boston Summit. > > from > http://mail.gnome.org/archives/gnome-shell-list/2010-November/msg00026.html > > >> • hide the tray icon if the shell is running and no channels need approving; > > >Actually, I've been asked to always hide it if the shell is running: > >https://bugzilla.gnome.org/show_bug.cgi?id=631944 > > >> • don't approve 1-1 Text channels if the shell is running; > > >What does that mean exactly ? Atm Empathy implements one Approver > >(Client.Empathy.EventManager). When a channel needs to be approved, this > >.event manager displays it: > >- As a notification bubble (with buttons if the notification daemon > >supports it) > >- In the notification area > >- In the contact list > > >So, if we disable the status icon (cf above) we'll still have the > >notification bubbles and the contact list change. Is that ok ? > > >(Actually that's not true because the notification bubbles are currently > >implemented with the status icon but that's an implementation detail, we > >should be able to easily separate them). > > So the goal is to not have a tray icon at all, but have Empathy send us > notifications about everything other than 1-1 Text channels. These > notifications will result in an icon in the message tray that shows the last > notification (or in the future all missed notifications) on click due to the > notification persistence support in the Shell. > > The contact list should reflect all the requests other than 1-1 Text requests > as well. The 1-1 Text requests should not be known to Empathy until the user > has explicitly transferred to the Empathy chat window. > > Actually, I wonder what should happen with the channel handling and > notifications about new text messages when the user > a) has the Empathy chat window open and focused > b) has the Empathy chat window open, but not focused > c) has closed the Empathy chat window > > Does Empathy redispatch the channel back to the Shell at any point? So, if I understand things correctly, we need to make the following changes in Empathy: 1) Completely disable the tray icon if the notification-daemon has the persistence capability. 2) Untangle the status icon and notifications code so notifications can be displayed even if the status icon isn't there. 3) IF gnome-shell is running, Empathy shouldn't act as a text channel approver. Is that right ? 1) and 2) are NOT gnome-shell specific hack while 3) is. We have to be careful here to not break things for people not running gnome-shell. Does gnome-shell override the notification-daemon installed on the system while running? For example, if I have gnome-shell installed but are not running it, will I still use the "normal" notification-daemon? We should display the the status icon in that case. To reply to your questions: a) No notification is displayed b) A notification is displayed only if the "Enable notifications when chat is not focused" option is enabled. c) Then the channel has to be re-approved by text approvers (Empathy and/or the shell).
(In reply to comment #12) > Is that right ? 1) and 2) are NOT gnome-shell specific hack while 3) is. > We have to be careful here to not break things for people not running > gnome-shell. Does gnome-shell override the notification-daemon installed > on the system while running? For example, if I have gnome-shell > installed but are not running it, will I still use the "normal" > notification-daemon? We should display the the status icon in that case. If you're not running gnome-shell, you'll have the "normal" notification-daemon, but in GNOME 3, the normal notification daemon supports persistent notifications too, so you can't use "supports persistence" as the switch for everything; whether you run the approver or not should be tied to whether or not org.gnome.Shell is present.
> So, if I understand things correctly, we need to make the following > changes in Empathy: > > 1) Completely disable the tray icon if the notification-daemon has the > persistence capability. > 2) Untangle the status icon and notifications code so notifications can > be displayed even if the status icon isn't there. > 3) IF gnome-shell is running, Empathy shouldn't act as a text channel > approver. > > Is that right ? Yes, all 3 sound right. > To reply to your questions: > a) No notification is displayed > b) A notification is displayed only if the "Enable notifications when > chat is not focused" option is enabled. > c) Then the channel has to be re-approved by text approvers (Empathy > and/or the shell). Sounds good.
The first step to be able to implement this would be for the shell to be a Telepathy Approver and Handler: bug #643594
We'll remove it when the Shell will be able to handle Telepathy events on its own: bug #653938
Actually the notification daemon supporting persistence is not enough to remove the status icon. What we want it to be sure that incoming messages, calls, etc will be displayed to the user. The Shell is now doing that (bug #653938) so we can remove it when the Shell is running.
Created attachment 195167 [details] [review] don't create the status icon if GNOME Shell is running
Attachment 195167 [details] pushed as cd4cb26 - don't create the status icon if GNOME Shell is running