Don't use a notification area icon in GNOME 3

[mccann]

In the upcoming GNOME 3 we won't be supporting notification area icons (status icons). Instead we will support persistence of notification bubbles. So that if a bubble is missed or not acted upon an icon will be added to a queue and provide basic equivalence to what status icons are today.

Transmission has an option in the Desktop tab of the preferences to "Show Transmission icon in the notification area". This should probably be removed.

Thanks for the great app! Please let me know if you would like a patch for this.

[charles]

looking at gtkstatusicon.h, it doesn't seem that status icons are deprecated or removed... do you have more information on why they aren't deprecated but shouldn't be used?

[mccann]

We haven't decided if they will be deprecated in GTK+3 yet. We likely need them for a few cases in our GNOME 2 fallback mode - but only for some system components like power and network. However, the notification area itself is deprecated. See: ​http://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Compatibility

[charles]

So now we can have three builds of Transmission that decide at compile time whether to use AppIndicator, GtkStatusIcon, or nothing at all, over such a stupid feature?

Removing it altogether, as you suggest, will hurt XFCE users.

I wish GNOME, Canonical, and everyone else involved would settle on one consistent API for this and stop fucking the app developers over.

In order for this ticket to move forward, I'd like you to tell me what change should be made to Transmission that will make it work properly, out of the box, on GNOME Shell, Unity, and XFCE.

[mccann]

I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I'm sorry that this is the case but it wasn't GNOME's fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry.

It is my hope that you are a GNOME app. Yes this kind of fragmentation is unfortunate. I'm not happy about it either. Anyway, I just wanted to give you a heads up. Wish you the best.

[charles]

Replying to mccann:

I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I'm sorry that this is the case but it wasn't GNOME's fault that Ubuntu has started this fork... It is my hope that you are a GNOME app.

*speechless*

[charles]

Jon, excuse me. I know this isn't your fault, and I shouldn't be attacking the bearer of bad news.

I find it exceptionally frustrating that there now seems to be three separate ways that we will need to code status icons next Spring. IMO this is not a good direction for the platform to be headed.

[mccann]

Charles,

I have great sympathy for your position. But what can I possibly tell you? We have no control over what Canonical decides to do with their OS. App indicators are an Ubuntu only feature.

FWIW, I don't think Transmission is at all impaired by removing all of above - app indicator and status icon. I have never used it with the status icon myself.

[mccann]

BTW, there is probably way to handle the XFCE case if it doesn't have a notification daemon that supports persistence. You can query the server capabilities of the notification daemon and see if it supports "persistence". See ​http://git.gnome.org/browse/libnotify/tree/tests/test-persistence.c for an example. Let me know if I can be of any further help.

[charles]

Would it be possible for GtkStatusIcon to handle all of this under the covers s.t. each application with a status icon doesn't have to reinvent the wheel in this regard?

[charles]

Jon, I think I'm asking the wrong question. Let me back up and describe my goals, and maybe you'll have some suggestions on how they can be accomplished in a compatible way.

• Many users leave Transmission running semi-permanently, but don't want the GUI to take up real estate, similar to how rhythmbox behaves. The notification area icon is a reminder that it's running, and also provides a context menu for few common background tasks -- adding torrents, stopping/starting torrents, and toggling the temporary speed limits.

• Separate to this, we also have optional transient popups that appear (1) when a torrent has been added indirectly (that is, without direct user interaction) and (2) when a torrent has finished downloading.

That summarizes what Transmission uses libnotify, GtkStatusIcon, and Application Indicator for. How much of these ideas (not code) can we preserve in GNOME 3?

[User294]

As for me, Gnome is going to become even worse than KDE4. who was horribly inclined on their stupid plasmoids but still haven't gone as far as to eliminate status icons in their madness.

As for me, I like status icons. And as user, I would never use environment which makes tracking status of semi-background-jobs anyhow harder or more intrusive (and torrent client and such are good example). It's so nice there is XFCE and others who do not want to reinvent the wheel, especially if it turns out to be square. Hell, yeah, I want to see torrent client's status near power and network status, can you imagine that?! And by looking on screen shots of Gnome Shell, looks like I can understand why Ubuntu has forked. They do care about user experience. And Gnome Shell ... uhm... on dev's place I would rather wait to see if such a Frankenstein could survive and if there will be enough users actually willing to use this horror, so supporting it will be anyhow worth of efforts at all.

[charles]

mccann: ping

[charles]

mccann: in addition, could you pass me a link to the discussion(s) of why the notification area has been deprecated? ​http://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Compatibility simply states the fact without describing the rationale. The TODO list for all the applications listed seems like a lot of work and I would like to learn more about the goals of the end result.

[charles]

ping?

[ted.gould]

I don't want to comment on what your application should do, but I do want to clear up a couple of the questions about AppIndicator. libappindicator falls back to use GtkStatusIcon if it detects that there isn't a KDE Status Notifier Item renderer. So on KDE or Ubuntu it will render in the standard case, but then with an other GNOME platform, older KDE or XFCE without the indicator module it will use the standard status icon interface. I hope that helps clear up some of the different cases.

[charles]

A month has gone by and I still feel like I don't have the information necessary to implement this in a way that will play nicely on the various fragmented platforms.

• Transmission is bundled on Fedora, which will use Gnome-Shell.

• Transmission is bundled on Ubuntu, which will use Unity.

• Transmission is bundled on Mint, which ​is apparently sticking with gnome-panel.

I'm not blaming upstream for this, nor Canonical, nor Clem. It's frustrating to be caught on the application-level for this, but in the bigger picture, I think this fragmentation is an interesting experiment.

So...

The reason this ticket's sat stagnant for a month is I don't understand what the next move is. Could someone from upstream please answer my questions that I asked a month ago in comment number 12?

Alternately, mcgann maybe I should take you up on your earlier offer for a patch... :)

[mccann]

The solution for GNOME 3 and the GNOME 2 fallback is the same: use a notification when the notification daemon supports persistence. Both the GNOME 3 and 2 fallback notification servers support persistence. So, the guidance from GNOME is consistent here and you shouldn't need to support two separate code paths. As for Ubuntu, I can't say. If you don't want to maintain an Ubuntu specific implementation they would probably maintain the patch in their packages for you.

[hadess]

Jordan asked me to make a comment here.

2 things need doing:

1. Add a tiny bit of code to gtk/notify.c to check whether the notification server has the "persistence" cap (just like is done for the "actions" cap in can_support_actions()), and export it in notify.h

2. If gtr_notify_has_persistence() returns TRUE, hide the preference for showing status icons, and just never show a status icon.

This should be enough to make transmission behave well with gnome-shell, and the GNOME 3 fallback. notify-osd doesn't support persistence. The only problematic one would be Mint if they had a newer notification-daemon, which they shouldn't if they're sticking with GNOME 2.

[hadess]

With the changes made to the status icon support, I guess this is fine to close now. Charles?

[fmuellner]

Disable status icon if the notification server supports persistence

[fmuellner]

I think it is still desirable from a GNOME perspective to disable the status icon completely. A patch implementing the behavior outlined in comment:22 is now awaiting moderation. There should be no change in behavior for non-GNOME platforms.

[guycohen]

As a user, I'd like to ask that you please do not disable the checkbox to enable a notification area icon. This would make it impossible to use the various GNOME extensions which (sanely) restore these icons. Without this sort of extension I personally would not be using GNOME at all. This is a matter for user/developer preference and applications should not be asked to only support the default behavior of the moment (whether or not it lasts).

[gvy]

Replying to mccann:

App indicators are an Ubuntu only feature.

So you propose a GNOME only "feature" of the lacking status icon.

Rant: I don't know the exact kind of disease someone's spreading in GNOME project since GNOME2 concept days but the feature of dropping every feature someone else might find useful is what should bury that clone project in the long term, and the less people are involved the better.

Disclaimer: I was told that some things like calendar were debugged for *years* in KDE4 due to the code in question being developed by schoolchildren, not even underexperienced students. The somewhat similar thing has happened to apache2 before. Call me a conspiracy theorist but looks like yet another "pure coincidence" to me, not even about talent pool drying up worldwide.

PS: my free software is about actually helping myself and others, not about forcing my stupid "brilliant" views onto each other's head and down their throats. It's also about educating people, not about helping those trying to dumb us down and look smart. It's about UNIX simplicity and elegance, not about mind-boggling chunks of ​MSDN camp type code.

Best wishes, and be healthy!

[pathetic_loser]

I'm using Transmission under XFCE. I also use status icon either. And I hate ways gnome guys are doing things recently. That's why I switched to XFCE. I can't get Gnome 3 doing things in way I would like.

[mike.dld]

#5702 and #5838 seem related.

[evgenyz]

GTK finally deprecated GtkStatusIcon.

​https://bugzilla.gnome.org/show_bug.cgi?id=734826

Any ideas on how to stay in «minimized to tray» state in the future as GTK app? As GTK app on GNOME?

[_mjog_]

It sounds like what is wanted is something like a desktop service. The correct way to build it would be to split out the backend out as a DBus activateable session service and make the frontends/GUIs communicate with that. When a frontend is first run the service would be automatically activated, and when the frontend exits the service can remain running in the background. When a frontend is run again, it reconnects to the already-running service.

This allows a GNOME client to have a reasonable GUI, and XFCE or whatever else can have a status-icon this or indicator-that that also communicates with the service via DBus.

[_mjog_]

Split the app up into frontend/GUIs and a backend desktop service that is activated by DBus. When a GUI is first run, the service is automatically started and can keep running after the frontend exits. When the GUI is re-opened, it connects back to the still running service.

This lets the GNOME frontend have a reasonable GUI, but also lets a system-icon-this or indicator-that also be provided for whatever odd desktop people want to use. ;)