GNOME Bugzilla – Bug 652122
AppIndicator support in the message tray
Last modified: 2017-08-29 21:36:41 UTC
I'm opening this bug because I have working code that lingers in my tree, and I know there is a GSoC for improving the message tray, I though you may find it useful. I think it was discussed that libappindicator + dbusmenu support was nice, although not encouraged for applications, so I think it should be part of core. By the way it needs some deep modifications in shell code (popupMenu.js and messageTray.js), so it cannot be implemented fully as an extension.
Created attachment 189478 [details] [review] AppIndicator: part one: the tray This commit adds a tray based on KDE/Ayatana/proposed Freedesktop protocol for renewed tray comunication. Icons following this protocol support menus, titles and tooltips, as well as providing status and category, thus allowing seamless integration in the desktop shell. In the Shell, they are rendered as Message Tray sources, with attached a Notification acting as the tooltip. Clicking on the notification brings the application forward, as usual. Next patch will add support for DBusMenu. https://bugzilla.gnome.org/show_bug.cgi?id=623656
Created attachment 189479 [details] [review] Message Tray: add hook for replacing the right click menu This patch adds a hook in Source for replacing the summary right click menu, making it a real PopupMenu (a PopupMenuEmbed, actually, but still exposing all the useful methods). Will be used for DBusMenu (and possibly extensions as well)
Created attachment 189480 [details] [review] AppIndicator: part two: menus over DBus This commit adds an implementation of DBusMenu, in pure JS + DBus, completing support for AppIndicator integration.
The message tray shouldn't have menus or tooltips. I think it is bad enough we still have status icons behaving inconsistently there why would we want to add another inconsistency and further fragment our API story?
(In reply to comment #4) > The message tray shouldn't have menus or tooltips. I think it is bad enough we > still have status icons behaving inconsistently there why would we want to add > another inconsistency and further fragment our API story? Because no matter what you say, KDE apps (as well as some GNOME apps) will continue to use their protocol, falling back to freedesktop system tray if not available, and StatusNotifierItem (AppIndicator) is way better than the old system tray. It is not adding inconsistency to the API because nothing is being added to the platform (neither Core Platform nor Extended Platform) - and that's everything a good developer should use. It is not adding inconsistency to the behavior because it shows a big black BoxPointer with summary and short status / description when you click on the summary item (like NotificationDaemon) and it shows a menu when you right click (like NotificationDaemon, just with more items than "Remove" and "Open")
The messaging tray is supposed to be for *messages*. Its purpose will be lost if it becomes polluted with mismatching pieces of functionality, and that'll make it more confusing for users and impair the quality of the user experience.
(In reply to comment #6) > The messaging tray is supposed to be for *messages*. Its purpose will be lost > if it becomes polluted with mismatching pieces of functionality, and that'll > make it more confusing for users and impair the quality of the user experience. Looking at designs at l.g.o/GnomeShell/Design/Guidelines/MessageTray, I don't see the message tray as a mere notification queue. It's seems instead the primary interaction point for background applications (email, music player, chat, microblog...). Btw this bug is about compatibility support, for apps that already use a StatusIcon there.
(In reply to comment #7) > (In reply to comment #6) > > The messaging tray is supposed to be for *messages*. Its purpose will be lost > > if it becomes polluted with mismatching pieces of functionality, and that'll > > make it more confusing for users and impair the quality of the user experience. > > Looking at designs at l.g.o/GnomeShell/Design/Guidelines/MessageTray, I don't > see the message tray as a mere notification queue. It's seems instead the > primary interaction point for background applications (email, music player, > chat, microblog...). > Btw this bug is about compatibility support, for apps that already use a > StatusIcon there. Each item in the tray is a message source. If you click on it, you are supposed to get the most recent message (ie. event) associated with that source. Clicking on the music player gives you the most recent song, for example. Appindicator support means that there will be more items in the tray that deviate from this message/source model.
(In reply to comment #8) > Clicking on the music player gives you the most recent song, for example. > Appindicator support means that there will be more items in the tray that > deviate from this message/source model. I don't think this is targetting the same applications. Apps that want integrate well with the Shell should and will use notifications (possibly resident ones). But some won't, because that's only supported by GNOME. For these apps, the idea is that we'd rather have them use the indicators API, which allows for more integration in the Shell (menus with out look and feel...) than the old tray icons, that don't integrate at all. That's especially something to consider WRT KDE apps.
(In reply to comment #9) > (In reply to comment #8) > > Clicking on the music player gives you the most recent song, for example. > > Appindicator support means that there will be more items in the tray that > > deviate from this message/source model. > I don't think this is targetting the same applications. Apps that want > integrate well with the Shell should and will use notifications (possibly > resident ones). But some won't, because that's only supported by GNOME. For > these apps, the idea is that we'd rather have them use the indicators API, > which allows for more integration in the Shell (menus with out look and > feel...) than the old tray icons, that don't integrate at all. That's > especially something to consider WRT KDE apps. If it's a choice between inconsistent integration and no integration, I'd choose the latter. :) You diminish the overall user experience otherwise.
(In reply to comment #9) > Apps that want > integrate well with the Shell should and will use notifications (possibly > resident ones). Indicators do something else than notifications, in that they give you visual feedback that your message source is still alive and running (and thus you can expect to be notified of incomming messages). They also give you a consistent place to start a message yourself. Notifications only act on incomming stuff. This is a part of design that GNOME Shell still seems to be missing, and is (combined with the minimization topic) also the source of repeated inquiries of people that want their non-GNOME apps to be nice Shell citizen. So far, I have no idea of how to be that.
Right now, you pretty much have to set up a resident notification with some actions on application startup, which is unbelievable. See bug #652217 for an example of what goes wrong when you do this. This should just *never happen*. We really, really need a way to support these sorts of applications, and this is something I've been pushing on a lot lately. I don't care how it's implemented technically, just that we have the use case for uninteresting windows and applications available.
(In reply to comment #11) > (In reply to comment #9) > > Apps that want > > integrate well with the Shell should and will use notifications (possibly > > resident ones). > > Indicators do something else than notifications, in that they give you visual > feedback that your message source is still alive and running (and thus you can > expect to be notified of incomming messages). They also give you a consistent > place to start a message yourself. Notifications only act on incomming stuff. > > This is a part of design that GNOME Shell still seems to be missing, and is > (combined with the minimization topic) also the source of repeated inquiries of > people that want their non-GNOME apps to be nice Shell citizen. So far, I have > no idea of how to be that. This is exactly why we shouldn't have appindicator support - people see that we support them and think 'I can do stuff with this that I can't with the normal framework, so I'll use that instead'. Introducing alternatives encourages inconsistency.
The goal is exactly that you can provide these use-cases with the normal framework, in order to get consistency. The Notifier Spec might be one way to achive that. Maybe you can think of better ones. As an application developer who wants to provide the best experience for his users on GNOME 3, I just care that something is provided, whatever it looks like. As a user, I care that something nice and useful is provided. An advantage of using some existing interface would be that you get support for it from other applications for free. Personally, I care enough about GNOME 3 to be willing to support a GNOME-specific solution, too. If you don't provide anything, applications will just do something. For example, I'll have to continue using the tray for now, ugly as it is. Others may choose to ship a home-brew extension. The result of this is consistency going down the drain.
(In reply to comment #14) > The goal is exactly that you can provide these use-cases with the normal > framework, in order to get consistency. The Notifier Spec might be one way to > achive that. Maybe you can think of better ones. > > As an application developer who wants to provide the best experience for his > users on GNOME 3, I just care that something is provided, whatever it looks > like. As a user, I care that something nice and useful is provided. An > advantage of using some existing interface would be that you get support for it > from other applications for free. Personally, I care enough about GNOME 3 to be > willing to support a GNOME-specific solution, too. I'm curious: what application is this? Why do you need something like AppIndicator? Probably there are better ways to do it and I think that's what the current Gnome designers intend, that developers _think_better_ about what the user experience is going to be instead of going with the easy solution of using AppIndicator or GtkStatusIcon.
While a little off topic (I could not find a more relevant bug), and feel free to ignore it (As it could easily be read as flamebait), This is the patch to 'fix' the 'statusIcons' going to the message panel. I've used this on a number of machines for a while, and it's one of the most infuriating design decision of gnome shell. About half the blog posts I've seen are for gnome-shell extensions appear to be just the ability to move a few specific status icon's back to the panel. The patch below fixes it for all of them. I have tried the 'message-area' way, it's difficult to be polite when explaining how bad a decision it has become. Accessing a feature of a status icon by pushing the mouse to the bottom, trying to get a message are to come up, trying to slide along the icons, and finally trying to avoid the notifications and actually press the icon to get them menu.. I would suggest you make the feature optional for people who like to torture themselves... for the rest of humanity please disable it. --- /tmp/statusIconDispatcher.js 2011-08-07 12:33:44.263977539 +0800 +++ statusIconDispatcher.js 2011-08-07 12:33:54.276027183 +0800 @@ -50,7 +50,7 @@ if (role) this.emit('status-icon-added', icon, role); else - this.emit('message-icon-added', icon); + this.emit('status-icon-added', icon, wmClass); }, _onTrayIconRemoved: function(o, icon) { @@ -59,7 +59,7 @@ if (role) this.emit('status-icon-removed', icon); else - this.emit('message-icon-removed', icon); + this.emit('status-icon-removed', icon); }
This feature conflict with the design, and the implementation is under discussion at their original place (it seems they want to replace dbusmenu), so closing.
This has been implemented as an extension: https://github.com/rgcjonas/gnome-shell-extension-appindicator
Also is now part of the native Ubuntu extensions: https://github.com/ubuntu/gnome-shell-extension-appindicator And also of the Cinnamon Desktop: https://github.com/linuxmint/Cinnamon/commit/01d2d51b05b16d229f9f2c0ac165597036c28889