Please, consider adding support for the Ubuntu AppIndicator standard. I know that this is probably against the current GNOME design, but there are still some applications that use tray icons and are hard to use on a stock GNOME because of the missing tray support.
Edited
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
I can't agree with this more. I'm switching between TopIcons, TopIconsPlus and others tray icons extensions (it depends which of them is currently working). I still can't understand why this was removed without any replacement.
For example try to minimalize Steam window, you can't even find it in the gnome shell (Super key) and this is not the only application that behaves like this.
Recently I tried to live without the tray icons and was badly surprised with dropbox not running for 14 days, because how should I know it's not running, if I can't see it in tray.
These are only a few examples of how annoying the situation without tray icons is.
@aklapper Yeah, I already mentioned this extension. My RFE is about adding this support directly into the GNOME Shell (or at least including this extension as a part of GNOME).
Andre Klapperchanged title from [RFE] Consider supporting AppIndicators to Consider supporting AppIndicators by default (instead of an extension)
changed title from [RFE] Consider supporting AppIndicators to Consider supporting AppIndicators by default (instead of an extension)
Andre Klapperchanged title from Consider supporting AppIndicators by default (instead of an extension) to Consider supporting AppIndicators by default (instead of a non-default extension)
changed title from Consider supporting AppIndicators by default (instead of an extension) to Consider supporting AppIndicators by default (instead of a non-default extension)
it would probably need some review to the protocol.
That's a very polite way of putting it
Essentially nothing of the previous evaluation was addressed, the dbus-menu stuff shouldn't be an optional extension (however we wouldn't want two remote presentation of menus, so any new protocol should use GMenu).
Plus a client library that takes a generic container (GtkMenu) and serializes the bits it can make sense of is a big big no-no.
That is, if we want to support a protocol for icon+menu app UIs, then it must be a new protocol (ideally based on GApplication). And that doesn't touch on the design side, it's a rather big if ...
I'm switching between TopIcons, TopIconsPlus and others tray icons extensions (it depends which of them is currently working).
I've agreed a while ago to maintain an officially supported fork, but it's currently stuck on a policy question. I have everything lined up to land the moment I know what UUID I can use on World/ShellExtensions, hopefully in time for 3.32.
I think that the reasoning for the decision to drop status icons largerly still stands, but I'm also conscious that status icons are a fairly standard desktop UI convention, and I'm open to revisiting the decision.
When we dropped support for status icons, one of the reasons was that the available protocols wouldn't allow us to do a nice UI for them¹. I can't say for certain, but if that were to change it might open up new possibilities.
¹ The things we were missing at the time were:
Measures to ensure that icons are monochrome (ideally they'd follow our conventions for symbolic icons, but I realise that's hard to enforce).
The ability to determine how and where status icons and their menus appear, so we can gracefully handle cases where there are a lot of them.
Giving users control over which indicators are displayed.
I would like to emphasize on the situation here: the issue is still here, one year after your comment @aday where you say you're "open to revisiting the decision", and three years after the decision to remove status icons. This means that there's been multiple releases by then.
The (non) status icons situation by default in GNOME Shell is still a major pain for me. Considering it's the 7th most popular issues, I would think I am not the only one thinking that. I hear your position on the matter, but right now this old and rather popular issue has been closed without any fix. Which, as users, is kind of like a slap in our face saying "we hear you, but we don't care".
I would like to go forward with this issue. No matter which solution is chosen, whether it is to officially support one of the extensions (e.g. @3v1n0's KStatusNotifierItem/AppIndicator Support) or to reimplement everything in GNOME. My wish is to see this feature addressed in the next GNOME roadmap.
I am using different, sometime open-source, applications that are in dire needs of status icons, like Nextcloud client, Riot, Steam, Teams, Remmina. Some of these applications, especially Nextcloud, are almost non-functional if there is no status icons. I can relate with @Zlopez and I keep switching between GNOME status icons extensions until there is one that dare to work. Nowadays KStatusNotifierItem/AppIndicator Support seems to be the best option. But even on a brand new Fedora 32 installation, this extension doesn't work all the time.. I don't understand why it works on one of my machine, but not the other.. Is it because I have autologin on the other, or because I am using multiple keyboard layouts?? It's hard to tell.
I love GNOME for everything else and I truly think it is an incredible part of the FOSS community. And to put my money where my mouth is, I gave 50$ to GNOME recently.
I think GNOME devs need to address this issue, I am simply and politely begging you.
The ability to determine how and where status icons and their menus appear, so we can gracefully handle cases where there are a lot of them.
That's an issue with XEmbed and "pure" status notifiers, because popping up the menu is up to the client (which usually involves a keyboard/pointer grab, so cannot be done where we already grab those ourselves).
It's not an issue with the dbusmenu stuff or an hypothetical GMenu-based API.
I've agreed a while ago to maintain an officially supported fork, but it's currently stuck on a policy question. I have everything lined up to land the moment I know what UUID I can use on World/ShellExtensions, hopefully in time for 3.32.
(except for the 3.32 timeline of course)
I'll ping on the policy issue, let's see if we can finally get this resolved ...
Ah right, I can reproduce that when I sign out. I guess it makes some sense for truly confidential issues (although I don't see it for this particular one).
Anyway, I got a reply on my ping that there isn't a conclusion yet
Extensions are well and good, but based on our recent long mailing list discussion, I think a reasonable interpretation of the discussion is that we have an emerging consensus that we should support indicators without requiring any shell extension.
However, I believe we also have at least a partial consensus, from the mailing list discussion, that that current implementations, including AppIndicator, have too many technical problems and are too controversial to support in their current form. Conclusion: if we add support for indicators, there would be no backwards-compatibility for existing applications. That won't please everyone, but it's the only path I see to a successful compromise here.
Certainly XEmbed is dead, and there is no desire to support those in any form. So that leaves AppIndicator, the topic of this feature request. I don't think it's a stretch to suggest, based on that mailing list discussion, that AppIndicator status icons could be supported in the future if certain unspecified changes are made to the spec, e.g. regarding D-Bus paths. Then gnome-shell could support only the newer version of the spec. Florian, do you agree? I believe you had some of the most serious concerns here, particularly including compatibility of the indicators with sandboxing. If we had a list of specific technical changes that are required, we could try to establish a consensus for those changes with the libappindicator and KDE developers. That would be a lot easier than creating a completely new spec for status icons. So if Florian agrees, I think the first step would be to create such a list of spec change proposals.
Then if we're successful in that regard, the only remaining problem would be to come up with a design. That's not an an easy problem, especially if we have a goal to keep the indicators out of the top bar, but our designers have already expressed interest in some form of status indicators, so it should not be a blocker either.
However, I believe we also have at least a partial consensus, from the mailing list discussion, that that current implementations, including AppIndicator, have too many technical problems and are too controversial to support in their current form.
It's not an implementation issue, it's the spec itself. We (or more specifically: Dan Winship) were asked for feedback around 10 years ago, but then the response to any issues brought up was "oh, we're not going to change that, take it or leave it". Which we did, just not the way the KDE/Canonical folks intended
Some of those issues were small-ish (but still ignored), like "don't assume windows are identified by a 16-bit integer" (whoops, wayland). But the main issue is quite fundamental I'm afraid: The spec defines a big list of properties an app can set, but allows the host to ignore everything with no feedback at all.
So let's say you want to indicate some event that requires the user's attention: You can set an overlay-icon property (don't remember how exactly it was called) or an icon-movie (for a bouncing icon or so) one, but as you don't know what properties the system actually supports, the icon may not change at all.
Fix that, and the embarrassing vagueness that resulted in the two existing implementations being incompatible with each other, and the client-side menus that face the exactly same issues as XEmbed (the dbus-menu extension is exactly that, an optional extension to the spec), and replace dbus-menu with GMenu (because I do not want multiple remote-menu implementations, thank you very much) and we are not looking at some spec tweaks.
That is, I don't want to support AppIndicators, and I don't want "AppIndicators 2.0" either.
If we are going to support something, then it should be something new based on org.freedesktop.Application and actions. And if we are going to create something completely new, then we should put design (and I mean UX, not API) first: If we aren't concerned with backwards compatibility, then hopefully we aren't bound by the icon-with-a-menu pattern either. Because frankly, allowing apps to pretend they are part of the system (which opening the system area to apps ultimately boils down to) isn't great to begin with.
The thread also brought up the idea of improving the running state tracking to include background apps (so no top bar icon, no menu). I still think that's much more interesting than the W95-style tray pattern, and with the recent work on the Background portal, some of the groundwork should actually be in place now.
OK, if it needs to be a new spec from the ground up, then I guess it needs to be a new spec from the ground up. And if you want a design first, I guess we should wait and see what our designers come up with.
We will surely need consensus from KDE for this to be successful, though, or we'll wind up with app menus 2.0.
Towards the end of that mailing list conversation, I wrote:
Since this spec is the closest we have to something workable, I think it would be productive to define the technical changes GNOME would want to see in order to support something close to it. Seems like our designers are willing to consider design changes, and the technical problems with the status notifier spec look like the biggest hurdles currently.
I don't think it's hugely problematic if our solution for status notifiers is not backwards-compatible with existing applications. KDE can be changed. So can libappindicator. Third-party apps like Dropbox will eventually be updated once Ubuntu adopts an hypothetical upstream GNOME solution for status notifiers, even if it takes a couple years. We don't have to solve everything overnight.
Third-party apps like Dropbox will eventually be updated once Ubuntu adopts an hypothetical upstream GNOME solution for status notifiers and drops support for its current downstream implementation, even if it takes a couple years.
I'm almost positive apps like Dropbox will take no action so long as Ubuntu does not require changes. So it's important to get buy-in from them not just on a new spec, but on dropping their current status notifier shell extension in the future once an upstream implementation is ready.
If the new standard implementation takes "couple of years", it means another couple of years of GNOME without a proper indicator support, right? I am not sure if this is the right approach. The idea of official GNOME tray icon extension (until a new standard is ready) sounded much better to me. :-)
According to the discussion above it's a "hypothetical upstream GNOME solution" meaning it's just talk at this point in time. so that would take a lot longer than a "couple of years".
ones there is a new standard then we could talk about the adaptation. for now I want (as a regular user) this "standard" to be a thing.
The idea of official GNOME tray icon extension (until a new standard is ready) sounded much better to me. :-)
That's indeed still the more immediate plan, but so far the code is still in my personal repo and moving it to the "offical" namespace is blocked by ongoing discussions on the board1. From an informal discussion at GUADEC I know that no visible progress doesn't mean that the issue has been ignored.
I know that this doesn't help you and other users, but in the meantime, the code is there (and I'll make sure it'll work on 3.34 on release day), albeit not on extensions.gnome.org.
There are legal questions involved, and "legal" more often than not means "slow"
We will surely need consensus from KDE for this to be successful, though, or we'll wind up with app menus 2.0.
I know about the good intention that is behind have just only one solution in a consensus, but if this intention fail, please don't desist of your original idea.
As a replace, an idea could be implemented something like this, but in this case it will be to swap from the DBusMenu to the GMenu model instead of what KDE create. That idea can also be used to reuse the current implementation of the StatusNotifier API. So, using an idea like that can add right now a lot of application to the new GNOME API, without need to wait for a change on that applications that currently only support the KDE way of the AppIndicator.
Also KDE can use again his original idea but now to support the new GNOME API for AppIndicators instead of only used it for the Global Menus that comes from the Gtk applications.
The problem that i see with the proposed solution is that have a performance implication, because is needed convert one representation to the other, but i think it's a little implication if we compare it with do nothing and i think finally both will win GNOME and KDE, because at less will be an alternative to reuse the work of the other without give up each own API.
I also want to shared some comments as someone that implemented a client of the DBusMenu API and the DBus-GMenu API in gjs:
The DBusMenu use an identifier (id) for the menu items, while in the GMenu model is suggested that this attribute (the id) could be omitted as is not "standard". I find pretty useful to have an identifier in the GMenu API as an "standard" attribute. This is because have an id will ensure to us have a way to compare menu items on a Menu layout updates and this will help to reused the same clutter actors. So, we don't need to delete one MenuItem actor and then create another when is the same real MenuItem, as we can reuse the same actor that Mutter know already how to paint.
After measure it for the performance point of view, I can say that on a big menu, the difference of have a mechanism to reused the MenuItem actors, its noticeable in comparative to not have that mechanism.
Another possible solution in my opinion would be displaying, for example, a green dot on an icon of a running application on Shell Overview and showing entries from the tray/appindicator menu when right clicking such application in Shell Overview. But that would of course require supporting the appindicator specification.
Maybe it makes sense but IMHO GNOME should be compatible (or at least try to be) with common design patterns. In all other OS-es/desktops "tray icon" are displayed are small icons on the panel.
@ToamszGasior: No, that is not correct. There is nothing here to be "compatible"; see the actual meaning of that word. Also see many many past discussions why "tray icons" are broken and wrong.
but we are still missing some important stuff from app that use appindicators, gnome people should be more cleaver to solve that problem, maybe make appindicators replacement that fits whatever we want to achieve, or reaching everyone and tell them to make app that fits our design, but seriously, i don't know what it's supposed to be, i think gnome people fail to educate their goal to people, or at least to app developers...
@fikrillah: Please post general meta-discussion comments on what other people or "gnome people" should [not] do in the forum or on the mailing lists as it is off-topic here. Thanks for your understanding.
ok. i'm sorry, i was not very polite here, but you guys should know i love what you guys doing, it's just me worried for not knowing stuff going on here...
@mcatanzaro This bug report was also about the official GNOME TopIcons extension fork that @fmuellner was working on and I believe is still "blocked by ongoing discussions on the board".
Don't you think an immediate solution should be found in the meantime? Some good ideas where given here. Maybe keep this issue open but change the title to something more generic like "Find an immediate solution for the application indicator issue (while waiting for a more definitive solution)".
Otherwise this issue will pop up over and over again for the "couple of years" ahead (see #2000 (closed)).
I think that may not be related here, as qubes appears to make heavy use of xembed-based icons, not appindicators. If there is desire to figure out how to get this to work on the gnome wayland session, feel free to discuss it on the gnome matrix or discourse.