+1

To further the "electron" comment, I find this particularly an issue with many flatpak applications which are probably using electron on the inside. For example, google play music, ferdi, slack.

A couple others to add to the list, telegram (which does notify using the normal notify but "minimizes to tray," solaar,

Also to note that web browser based applications in Chrome/Chromium (and possibly also Firefox) would also make status notifier items and those applications cannot be quit without access to those notifier icons.

Ubuntu also preloads this extension. Fedora looks bad when an application works correctly on other distros but not on Fedora. Having feature parity in this area would be beneficial to users. The extension appears to be well maintained, with routine development, releases, issue responses, and merged pull requests. I'm not part of the workstation working group, but for whatever it's worth I'm in favor of this idea.

Some screenshots of the extension in action, while running Dropbox, Telegram, and Steam. Dropbox doesn't show for some reason.

The behaviour of the extension with Hexchat leaves something to be desired:

• The menu behaves differently to the others. Instead of opening the menu, left click toggles minimize/unminimize, and right click shows a GTK menu which appears over the other side of the screen. (This inconsistency from the other menus was pretty confusing to me at first.)
• Somehow - I don't know how - I ended up with two Hexchat instances via the menu, each with their own status icon.
• In some situations, right clicking on the icon crashes Hexchat.

Another note from my testing: there's an obvious conflict here between the menu items and the "run in the background" portal permissions we show. I've got those for most of the apps that are showing icons in the top bar.

The icon and the dialog serve the same purpose and it feels a bit annoying to have to deal with both.

I think Hexchat, being GTK2, actually uses XEmbed. In my experience, the XEmbed support isn't very good.

Actually, now that I think about it, it probably isn't working at all since you're in Wayland. If you run in X11, does the Hexchat icon show up? If so, that's XEmbed.

+1

I have had many conversations with people who have said they do not use GNOME specifically because they can't interact with a lot of the apps they use due to the lack of system tray / status notifiers in GNOME. This is one of the most common complaints I've seen in comments for my podcasts, my videos and just in the general community.

Some applications work better with system tray support and some others require it.

For example, Element (electron based Matrix client) is structured in such a way that you can not close the Element app without using the system tray menu. If you close it in the dock or whatever it will close the window not the application. To perform a true exit of the application you must use the system tray menu. This can be argued as bad design but this is a very common implementation even with incredibly popular apps.

In my opinion, system tray functionality is not a luxury it is a necessity so with GNOME not having one, it makes me feel like it is putting Linux in a bad light because some people who don't understand why they cant use those features will just think that Linux is buggy and can't run the apps correctly.

I'm in favor of this suggestion.

I see it coming up a lot in user comments, most recently just the other day on Ask Fedora: https://ask.fedoraproject.org/t/can-backgrounded-apps-show-an-indication/17005

I've read Allan's blog post linked there from a while ago, and I'm super-sympathetic to the justification — these status icons in practical use are kind of a horrible mess.

But, think we're going to need to use a different lever to change software designs, especially with other distros installing this by default. (I see it's also the fourth most popular extension at https://extensions.gnome.org/.)

We may be able to fix stuff like Solaar (a horrible hack but it makes my high-res logitech mouse usable), but... in the meantime, there's Zoom just happily leaving itself in the background (same thing as Michael's example of Element). At least with the status icon I can remember to close it.

About the hexchat icon (which defaults to off in the hexchat settings IIRC) this indeed is using the old Xembed protocol (through Xwayland in a Wayland session).

When gnome-shell-extension-appindicator grew support for legacy tray-icons, I ran a bunch of tests and I filed some bugs upstream against gnome-shell-extension-appindicator for some Xembed issues. Note all the issues also existed under TopIcons before and gnome-shell-extension-appindicator upstream is actually trying to fix them.

One of the issues which I filed is for the right click popup menu location being in the wrong place which @aday noticed, this is being tracked here:
https://github.com/ubuntu/gnome-shell-extension-appindicator/issues/298

FWIW +1 for the proposed change from me too.

I've also had issues with the Dropbox entry. Neither left nor right click raise a menu. Double-click raises a non-shell menu which is positioned on the other side of the screen and can't be hidden.

The working group discussed this issue yesterday.

• In general the group is supportive of the general idea.
• There's a desire to tighten up the appindicator spec.
• We feel that it's important to work with the gnome-shell maintainers as much as possible.
• If we do adopt the appindicator extension, then its important for it to the same as what's used in Ubuntu.
• There are open questions around the desired UX, how this would fit with classic mode, what to do about RHEL, and so on.

We plan on investigating each of these points in more detail.

The GTK-ecosystem implementation of SNI (commonly known as AppIndicators) has been forked into the Ayatana Indicators project. @rdieter and I have been looking at what we need to do to switch our appindicator implementation libraries to the actively maintained fork.

The GTK-ecosystem implementation of SNI (commonly known as AppIndicators) has been forked into the Ayatana Indicators project. @rdieter and I have been looking at what we need to do to switch our appindicator implementation libraries to the actively maintained fork.

I'd be interested in helping with this, since I'd like to get application indicator support in Pantheon enabled on Fedora, but the current state of the "ecosystem" is pretty bad.

I really like the idea of GNOME (or Fedora) support a status notifier like feature. I do however have great concern with the existing implementations and do not think we should use them. I understand that compatibility with existing implementations is appealing though.

StatusNotifier itself isn't an ideal spec, it is vague, it doesn't align with how modern DBus works (they use custom signals instead of org.freedesktop.DBus.Properties), it is counter to how sandboxes work (ownership of well-known bus names), it isn't actually respected in practice (libappindicator does spec-breaking behavior), It has complication that make compliance for applications hard (how StatusNotifierHost is exposed).

To make things worse the Menu property requires implementing the DBusMenu spec which is an extremely complex standard that was designed to do something we are not doing, completely reproducing entire toolkit menus in external windows. libdbusmenu is a very dead and rotten library which will be only harder to support as time goes on. There are examples of more simple specs to provide exactly the functionality needed in this case, notably GMenu which is trivial to use or implement from scratch.

Lastly the Ayanata project is an API break, so it will require patches to every project to use it anyway.

I think a new solution is the best way forward and would not be a difficult task.

Any new solution would need a way to have the old stuff work, so that immediately makes it a difficult task. See the X11->Wayland transition, and amplify that by 100x.

We already need applications to migrate to new solutions to work in Flatpak for example. libappindicator comes from a different time with different goals and I don't think we should keep it alive.

This is nowhere near X11->Wayland. This is roughly an API consisting of half a dozen simple DBus API calls in total. The kind of thing a developer can write from scratch in an afternoon.

We already need applications to migrate to new solutions to work in Flatpak for example. libappindicator comes from a different time with different goals and I don't think we should keep it alive.

This is nowhere near X11->Wayland. This is roughly an API consisting of half a dozen simple DBus API calls in total. The kind of thing a developer can write from scratch in an afternoon.

If it's so simple, then there's no reason for not having a shim.

Yes, a shim can be done.

Neal, it's pretty amazing that you managed to convince GNOME devs to seriously consider status notifiers at all. I mentioned previously that upstream is very unlikely to accept compatibility with existing applications. Let's focus on working with upstream and coming up with something that can be implemented directly in GNOME shell, without requiring downstream extensions that are so prone to breakage, so we have something nice that applications can use going forward. If providing compatibility with existing (broken!) applications is required, we're probably going to remain stuck with something upstream will not accept. If we care about ensuring status notifiers work for applications that use flatpak, a shim seems counterproductive rather than useful, since it would discourage applications from using the newer API.

One more problem: we still do not have any design for how this should look. :)

Neal, it's pretty amazing that you managed to convince GNOME devs to seriously consider status notifiers at all. I mentioned previously that upstream is very unlikely to accept compatibility with existing applications. Let's focus on working with upstream and coming up with something that can be implemented directly in GNOME shell, without requiring downstream extensions that are so prone to breakage, so we have something nice that applications can use going forward.

In order for your strategy to work, we would need both KDE and GNOME to develop the new standard together. GNOME cannot design a new standard alone, because that is absolutely doomed to failure because then applications have to choose between an API broadly adopted (SNI) and one that only exists in one place (this new thing). I can try to find someone on the KDE side to engage with on this front, though.

If providing compatibility with existing (broken!) applications is required, we're probably going to remain stuck with something upstream will not accept.

The first thing I want to state here is that we can't call these applications broken. They're not. Fundamentally, the problem here is that the GNOME Shell does not provide an adequate model to interface with applications that have this very common paradigm. We may not like it, but that's how things are.

I am fine with shipping something short-term that I know upstream will not accept. In fact, I made this ticket with the explicit expectation that may not be possible at all to resolve this upstream. I was more than well aware of the upstream issues when I filed this ticket. I want to solve problems for users first and foremost, so that Fedora is considered one of the standard choices for a Linux desktop, if not the choice.

If we care about ensuring status notifiers work for applications that use flatpak, a shim seems counterproductive rather than useful, since it would discourage applications from using the newer API.

I do not agree with @tingping's statement that SNI can't work with Flatpaks. That's very obviously not true, given that SNI is a D-Bus based API and all D-Bus APIs can be mediated in Flatpak, and they have to work now because otherwise KDE Flatpaks and many Electron apps would be utterly broken on desktops that support SNI (all but GNOME). On my KDE Plasma desktop on Wayland, apps delivered as Flatpaks (such as Discord) show their status notifier items just fine, and they work properly (actions accessible, etc.).

Critically, how do you suppose we get anyone to adopt the new protocol fast enough to make an impact? We have a decade-long tail of things that people actively need to use, and Fedora should work out of the box for those people while things change over. I'm fine with such a solution existing downstream, but we cannot ignore the fact that it's a problem.

One more problem: we still do not have any design for how this should look. :)

I provided a textual concept of how it could work for GNOME. I'm sure @aday can turn that into a mockup of some kind and that can start a discussion about how to integrate that into GNOME Shell. And even without that, we do have a design: the one that's currently used for the existing extension. Design is the only thing I'm not worried about.

But if design is something we need to hash out, then I think it'd be worth connecting with @ngraham on the KDE side to make sure that both desktops are considered.

I do not agree with @tingping's statement that SNI can't work with Flatpaks. That's very obviously not true, given that SNI is a D-Bus based API and all D-Bus APIs can be mediated in Flatpak, and they have to work now because otherwise KDE Flatpaks and many Electron apps would be utterly broken on desktops that support SNI (all but GNOME).

Per the spec:

Each application can register an arbitrary number of Status Notifier Items by registering on the session bus the service org.kde.StatusNotifierItem-PID-ID, where PID is the process id of the application and ID is an arbitrary numeric unique identifier between different instances registered by the same application.

• PID's are useless in pid-namespaced sandboxes (real world apps are broken here, they all try to own the PID 2 because they are all the same in every sandbox)
• name ownership is explicitly forbidden unless a permission is granted to the flatpak
• The watchers bus name is hardcoded to be org.kde.StatusNotifierWatcher. DBus talk permissions are forbidden to this namespace unless explicitly granted.

Even worse org.kde.StatusNotifierItem-PID-ID is not properly namespaced. So you must grant ownership permissions to all of org.kde.* for it to work in flatpak. This means all kde flatpaks can pretend to be any kde service. All security is currently lost.

I think it'd probably be better to focus this ticket on what we can do here in the short term, and open a separate issue (or start an initiative in some other way) to address the big picture and future upstream improvements.

I think it'd probably be better to focus this ticket on what we can do here in the short term, and open a separate issue (or start an initiative in some other way) to address the big picture and future upstream improvements.

I think we can land a new spec for F36 if @tingping is interested in continuing this work. Would require coordination with KDE.

Anything short of that is unlikely to be fruitful since many of us are going to be very reluctant to ship downstream extensions that are fragile and unlikely to match an eventual upstream solution.

I think it'd probably be better to focus this ticket on what we can do here in the short term, and open a separate issue (or start an initiative in some other way) to address the big picture and future upstream improvements.

I think we can land a new spec for F36 if @tingping is interested in continuing this work. Would require coordination with KDE.

How will you get anyone to use it? How will existing applications take advantage of it? How does it solve the problem we have right now?

Anything short of that is unlikely to be fruitful since many of us are going to be very reluctant to ship downstream extensions that are fragile and unlikely to match an eventual upstream solution.

"Fragile" is not a word I would use for an extension that's actively maintained by a distribution that operates in the GNOME ecosystem and generally tracks GNOME.

gnome-shell-extension-appindicator co-maintainer here.

Right I don't understand all the arguments about the appindicator extension being fragile. It is actively being maintained by its upstream. Reported issues are resolved in a timely manner and updates to work with new GNOME releases also are made available in a timely manner (typically before the beta release of a new GNOME release).

Short term it really is best to just add gnome-shell-extension-appindicator to the default workstation package-set. Also notice that this is an almost 0 effort thing to do. The extension is already packaged and actively maintained, it is just a comps change.

I recently published an article on Fedora Magazine, in which I actually recommended users to install the gnome-shell-extension-appindicator because it is necessary for using popular applications like Steam, chat applications, and screen recorders like OBS.

Gaming on Fedora
https://fedoramagazine.org/gaming-on-fedora/

If Fedora 36 could come pre-configured with the App Indicator, then that would save us all a lot of headache in the future. We can then support the majority of users and their applications right from the start.

As for putting this issue on the agenda upstream... that's not a hill I intend to die on.

I don't think doing this via downstream shell extensions makes sense. Upstream is the only way. And the issues identified by TingPing seem sufficiently serious to kill any suggestions that we support the existing status notifier spec, upstream or downstream. We're simply going to need a new spec, or else major changes to the existing one. There's obviously no way to make this work for sandboxed apps, and surely we should not be adding new things that don't work in sandboxes, or encouraging applications to run unconfined. No way.

A new spec will not be adopted if we offer compatibility with existing applications that depend on the old broken spec, so the path forward is to create something new and better, as part of GNOME upstream, hope applications will adopt it if they wish to be compatible with GNOME, and try to convince Ubuntu to drop their existing extension in order to nudge apps to upgrade.

Perfect is the enemy of good.

A quick glance at the Fedora Project YouTube screen-casts actually reveals that 90% of all contributors/employees use the App Indicator, so the discussion on whether or not it's a proper or secure standard is irrelevant. People, including 90% of the people in this discussion, use it. That's also why I prominently mentioned it in the Fedora Magazine, most of us use it and others will want to use it too.

I would encourage upstream to make a better proposal which can replace the current implementation, but they should realise that until there is a better alternative in place, everybody will just use the existing product. As mattdm mentioned; Let's focus at the problem at hand and let GNOME stress over the future replacement.

Either way, those are my two cents and if Fedora 36 doesn't have App Indicators out of the box, we can always dedicate another Fedora Magazine article to it so that people can use their preferred chat app.

Perfect is the enemy of good.

It just does not meet our quality standards for Fedora or for GNOME. Frankly, it is unworkable trash. I mean, come on, requiring applications have D-Bus access to own all of the org.kde.* namespace is clearly unacceptable. After seeing TingPing's analysis, there's just no way to convince me to vote in favor of the existing spec.

I would encourage upstream to make a better proposal which can replace the current implementation, but they should realise that until there is a better alternative in place, everybody will just use the existing product. As mattdm mentioned; Let's focus at the problem at hand and let GNOME stress over the future replacement.

We are upstream people too, and the purpose of this ticket is to do exactly that: create a proposal. I know somebody had recently started work on this actually, and I'll ask to see if that's ready to be posted here.

@tingping I found your old blog post https://blog.tingping.se/2019/09/07/how-to-design-a-modern-status-icon.html, which is very relevant for this issue.

• PID's are useless in pid-namespaced sandboxes (real world apps are broken here, they all try to own the PID 2 because they are all the same in every sandbox)

A few more things:

• Silverblue is intended to replace Workstation
• In Silverblue, everything is a flatpak
• Each flatpak app thinks it is pid 2

It's hard to see how it would be possible to support existing solutions without messing up our future.

Plan should be something along the lines of:

• Create new freedesktop.org standard for status indicators, implement it in both GNOME and KDE. Obviously buy-in from KDE is required because we don't want to do anything that would be specific to GNOME alone.
• libappindicator and KDE client libs both support hypothetical new standard. Open source apps don't need to do anything, they just start to work.
• Proprietary applications get updated to newer libappindicator at the pace they update such things, which might be five years from now, but eventually they mostly do update eventually.
• Critical: if you want to show an indicator in GNOME without requiring that users install special extensions then you must use the new standard. This is essential for encouraging proprietary apps to update, so people can flatpak them properly. Otherwise the indicators are going to be broken under flatpak, which is unacceptable.
• Final step: convince Ubuntu to drop their extension, so proprietary apps that only care about Ubuntu have proper incentive to update.

Oh, I almost forgot about the other major missing piece here: design. This is orthogonal to the technical issues discussed above. We are still waiting for a design for what status indicators should look like. This might be hard because some of us are very much hoping to not allow applications to add distractions to the top bar. Maybe they could go into the shell dropdown menu instead? Or maybe they could be part of the overview somehow? I know @aday has an action item to investigate possible designs.

Design is much lower-stakes because we can change it in the future without breaking anything, unlike the D-Bus spec.

gnome-shell-extension-appindicator co-maintainer here.

Right I don't understand all the arguments about the appindicator extension being fragile. It is actively being maintained by its upstream. Reported issues are resolved in a timely manner and updates to work with new GNOME releases also are made available in a timely manner (typically before the beta release of a new GNOME release).

Came here to say this too. It's actively maintained by Ubuntu, and to my surprise, even in F34 / GNOME 40 it's one of the few extensions that actually works from the get go.

There are too many applications that rely on this - many have already been mentioned (and for some of them e.g. Dropbox I doubt they'll quickly adopt a new API). I don't think Nextcloud's client has been mentioned, but it's there too, as well as some that are actually developed at Red Hat like Virtual Machine Manager.

Short term it really is best to just add gnome-shell-extension-appindicator to the default workstation package-set. Also notice that this is an almost 0 effort thing to do. The extension is already packaged and actively maintained, it is just a comps change.
+1 - this in the short term, to be followed by a new standard jointly developed by GNOME and KDE, with a shim, sounds ideal.

• PID's are useless in pid-namespaced sandboxes (real world apps are broken here, they all try to own the PID 2 because they are all the same in every sandbox)

A few more things:

• Silverblue is intended to replace Workstation

Speaking as someone who used to maintain a large desktop fleet -- we looked at Silverblue a while back, and it's just so different from how we managed our fleet of machines that we'd have to develop brand new management tools -- think of how Chromebooks can be managed from a centralized API - to even consider making a switch to it. And our Linux fleet is a minority so this is rather unlikely to happen.

Oh, I almost forgot about the other major missing piece here: design. This is orthogonal to the technical issues discussed above. We are still waiting for a design for what status indicators should look like.

I think that, from a design perspective, status indicators are considered to be a compatibility feature for apps/frameworks which don't exclusively target our platform. The design isn't for ideal app behaviour but more for what the fallback should look like.

In this case, I think that the design would mostly be a refinement of what's there already - a series of icons in the top bar, each of which can trigger a menu. It's important that the icons are monochrome. Ideally, they'd follow the standard symbolic style. I'd also be interested in exposing configuration to allow users to block particular apps from showing a status indicator.

We could potentially explore a way to show/hide the icons, or collapse them down in the event that there are a lot of them, but I'm not sure that that needs to be in scope initially.

Obviously there are more details to work out, but that would be the general gist of it.

I don't think we — Fedora, or even all of GNOME together — have the leverage to force behavior. The sad reality is we're much more likely to just get dropped, and probably blamed in the process. We're basically mostly hurting 1) our users and 2) ourselves.

There's got to be some carrot-based approach to getting software to change to a new model.

It's important that the icons are monochrome. Ideally, they'd follow the standard symbolic style.

gnome-shell already knows how to convert fullcolor PNGs to monochrome, so that will be fine, although they might not look very amazing. With spec changes we could allow apps to set both fullcolor and monochrome icons and allow the desktop to choose which to use.

Ack for the other details.

I'd also be interested in exposing configuration to allow users to block particular apps from showing a status indicator.

That seems pretty useful indeed.

There's got to be some carrot-based approach to getting software to change to a new model.

The only possible carrot is to let apps do something they cannot otherwise do: show a status indicator. We have no other leverage.

Speaking with my developer hat on:

Having good library bindings (for a few major languages), or even official (?) GUI toolkit support (GTK, Qt, Electron?) that wraps the yet-to-be-designed new ApplicationStatusIconMenu :tm: (DBus) API for easy consumption would be a pretty good carrot, IMO, considering that the original ayatana (lib)appindicat(e|or) libraries and ecosystem has been pretty much bitrotting for a decade, accumulating usage of deprecated platform APIs and have increasingly ancient build tooling etc.

Combine "this is the modern way to do things" with "this does what you want and more, and works more reliably and is more secure and is future-proof, so do this instead of the old thing" should be an easier sell than just telling application developers "there's no replacement for this, but stop using it".

Hope that makes sense, it's been a long day.

Having good library bindings (for a few major languages), or even official (?) GUI toolkit support (GTK, Qt, Electron?) that wraps the yet-to-be-designed new ApplicationStatusIconMenu ™ (DBus) API for easy consumption would be a pretty good carrot, IMO, considering that the original ayatana (lib)appindicat(e|or) libraries and ecosystem has been pretty much bitrotting for a decade, accumulating usage of deprecated platform APIs and have increasingly ancient build tooling etc.

I really think we can update libappindicator (and any similar libraries?) to use the hypothetical new spec, because apps not having to do anything except upgrade a library is better than having to do porting work. It should go fine. I think. Probably.

There is another problem with making a new App Indicator API, which will also really hamper any future adoption; Electron.

Love it or hate it, Electron is what powers most chat-clients, who all use indicator icons. Electron is being maintained by Google and they have the policy of supporting every Ubuntu TLS release. As such, many new desktop features can only be added to the Electron framework once Ubuntu has them available. Better yet, that means that any API you come up with, will have a 5 year incubation period. If you publish a new App Indicator API today, it will be until ~2027 before Electron apps are going to support it.

This is not idle speculation btw, this also happened with GtkFileChooserNative API. Published in 2015, implemented in Electron this summer. Some chat applications still don't have it because they too need to update their framework.

This gives two issues:
- Any gradual migration is unrealistic
- What should users do in the coming 6 years

There is another way though, which is the carrot that mattdm is referring to. One management idiom that comes to mind is; "Renovating the kitchen while keeping the restaurant open". GNOME should first implement the existing API so that partners like Canonical can switch to that implementation, and then over time GNOME can add advanced features that use the new, more secure API.

What are those advanced features supposed to be? Hard to know, but you can offer better theming-integration, integration with the notification system. Perhaps even more, but then we should take a look at Mac OS and Windows 11, and how they do it.

Back to Fedora Workstation discussion! Since Fedora Workstation needs to do something between now and 2027 (Expected time-to-market of the GNOME App Indicators), I support bundling and enabling the existing app-indicator plugin.

Damn. Now I am participating in this discussion, while I initially wanted to avoid it. Hope it helps though.

@jwrdegoede Can we disable legacy XEmbed support in the appindicator extension? That's the most problematic part of the extension, and it'd be good to disable that for the preloaded variant.

@catanzaro

It just does not meet our quality standards for Fedora or for GNOME. Frankly, it is unworkable trash.

Please do not refer to other software this way. Such language is not in line with the Fedora "Friends" Foundation or the standards laid out in our Code of Conduct.

@aday:

I think that, from a design perspective, status indicators are considered to be a compatibility feature for apps/frameworks which don't exclusively target our platform. The design isn't for ideal app behaviour but more for what the fallback should look like.

In this case, I think that the design would mostly be a refinement of what's there already - a series of icons in the top bar, each of which can trigger a menu. It's important that the icons are monochrome. Ideally, they'd follow the standard symbolic style. I'd also be interested in exposing configuration to allow users to block particular apps from showing a status indicator.

I was not aware there's a standard for doing monochrome/symbolic icons. KDE Plasma and other desktops seemed to lack the ability to use this like GNOME does, which makes me think it's not actually standardized.

We could potentially explore a way to show/hide the icons, or collapse them down in the event that there are a lot of them, but I'm not sure that that needs to be in scope initially.

It would be good for future iterations, yes, though if we can squeeze it into an initial implementation, that would be very nice.

Obviously there are more details to work out, but that would be the general gist of it.

Indeed.

agrees with @ngompa might be good to use https://extensions.gnome.org/extension/615/appindicator-support/ also in Fedora, i am not against Appindicators

Consensus seems to be that we should try to develop an upstream solution first, and only use an extension if upstream efforts fail.

Edit: I've moved the rest of this comment to #264.

@bittin @catanzaro I think that we should keep the discussion focused: This is about the here and now.

There is a de-facto, supported standard right now. Until there is a new, official, supported standard, we must do something. That new standard will be no earlier then 2027, and this issue is about addressing the problem between now and 2027.

Most of what I had to say on the issue and the problem of backwards compatibility is in my earlier comment: https://pagure.io/fedora-workstation/issue/246#comment-761751

In fact, with the release of Ubuntu 22.04 LTS approaching soon, I think it's reasonable to push the GNOME App Indicators platform back to 2029. It would be really great if Ubuntu 24.04 LTS can have the new, backwards compatible App Indicator API, for else we won't be able to close this epic issue within this decade.

2029... Fedora Workstation should do something until then. "Perfect is the enemy of good" and if we're the only mainstream distribution without App Indicators, then that only hurts us.

Edit. I really respect Canonical for standing up on behalf of their customers and business partners. they won't break the workflow of their users, and they won't alienate companies with a single vision. Annoying if you want to implement a new framework, but that just means that developers need to seriously consider backwards compatibility and continuity.

Hi, the reason we want to start upstream first is that an upstream solution will necessarily not have any backwards compat (all existing specs are a hard no upstream), and we don't want to add support for existing apps in F36 only to remove it in F37 (I don't think it will really take until 2027, how fast simply depends on how many contributors take interest, see #264).

I'm not sure what the de-facto standard is, honestly. There are five different standards right now (GtkStatusIcon, Canonical appindicator, similar but incompatible KDE status notifier, similar but incompatible ayatana appindicator, plus whatever Linux Mint is doing). None of them will ever be supported by GNOME (again, see #264), and supporting them downstream forever would be maintenance burden. Having agreed to add the status indicators, it would be beneficial to take the time to do it properly such that the work can go upstream and benefit all distros, rather than be an extension that we have to maintain downstream forever (even if Hans is willing to help with that -- thanks Hans -- I'm sure having upstream support for indicators would be even more desirable).

We know about Electron: with any new spec, existing Electron apps' status icons will not work until Chromium is updated and the apps bundle a new version. That's OK, because those apps currently do not display any status icon in Workstation anyway. The prospect of being able to show a status icon is a carrot to update. If we add a compat extension temporarily, it becomes much less OK to rip it away in the future. Fortunately, it's unlikely that individual applications would require code changes to be compatible with a new protocol (beyond updating their bundled libs) because we should only need to change the client libraries that they use (known libs: libappindicator, KStatusNotifier, Chromium/Electron, more? anataya? xapp?).

Please also consider this from the perspective of a sandboxed application. We really don't want to design for insecure applications that have full access to your entire session bus, access to icon paths on the host filesystem, access to host pid namespace. Indicators are currently actually an incentive to not properly secure your application. That's not a good incentive for app developers.

If we do this properly, with buy-in from at least Ubuntu and KDE so that any new standard is truly widely-adopted, then we'll be in a much better position five years from now than if we were to simply go ahead and adopt the extension. Yes, it's tougher for users in the short-term, but you can always install the extension manually if you really want it. But if we simply install the extension now, then we'll all stop working on this and there's no more incentive to fix indicators going forward.

all existing specs are a hard no upstream

Then I don't think that they will succeed before 2027. They failed with the GtkFileChooserNative API, which was not adopted until after Ubuntu 16.04 was EOL. I don't think that the new Indicator API will have better luck.

That's OK, because those apps currently do not display any status icon in Workstation anyway.

And that's very bad, because the Fedora Workstation should empower people today and not in 2027. The Fedora Workstation team should not inconvenience their users intentionally, and the 'carrot' you talk off is not there. Applications like Steam and Discord already have icons... Fedora Workstation is not even part of there supported Linux Distributions and this won't change any time soon. Ubuntu is the standard.

If we do this properly, with buy-in from at least Ubuntu

Judging by previous experience (Indicators, App Menu, desktop icons... all that stuff), they will respect their current users and businesses and they won't break their workflow. Stalling GNOME's project until 2027... if it will ever even be backwards compatible. In 2030 we'll possibly have two standards: 1 that every Ubuntu-compatible application uses, and 1 that is sandboxed.

But if we simply install the extension now, then we'll all stop working on this and there's no more incentive to fix indicators going forward.

So you understand that the current path is doomed! You might just as well stop now with the Indicator project, since everybody installs the extension now anyway. The conflict of interest between the 'Fedora Workstation'-group and the GNOME developers is clearly not in the workstation's favour here.

GNOME App Indicators won't happen unless the project changes course and it sets out for a multi-year, backwards compatible, migration project in collaboration with Canonical, respecting their users and business partners.

I encourage Fedora Workstation to not use their users as technological leverage for an API that might never be.

I'd like to keep this discussion at a more restrained level of rhetoric - I don't think there's any need for grand pronouncements about what path is doomed. :-)

We're definitely not precluding offering backwards compatibility with current library APIs and/or protocols. That's likely a necessary part of a solution, whether implemented in GNOME Shell proper or in an extension. But knowing what the end goal is makes that much easier. Especially when trying to be compatible with several complicated and inconsistent specifications.

A) Figure out what parts of the current standards are in use and needed in a joint discussion as part of coming up with a new standard (which might just be a revision/clarification of an existing standard.)
B) Figure out what UI and implementation is needed for those features
C) Map legacy APIs/protocols onto that UI and implementation

all existing specs are a hard no upstream

Then I don't think that they will succeed before 2027. They failed with the GtkFileChooserNative API, which was not adopted until after Ubuntu 16.04 was EOL. I don't think that the new Indicator API will have better luck.

That's OK, because those apps currently do not display any status icon in Workstation anyway.

And that's very bad, because the Fedora Workstation should empower people today and not in 2027. The Fedora Workstation team should not inconvenience their users intentionally, and the 'carrot' you talk off is not there. Applications like Steam and Discord already have icons... Fedora Workstation is not even part of there supported Linux Distributions and this won't change any time soon. Ubuntu is the standard.

So here's the thing: Fedora Workstation WG members have contributed to Chromium, which is the core of Electron. We are definitely capable of making the necessary adjustments upstream if we can get a protocol hammered out. We've done it before and we can do it again.

Your argument about waiting until 2027 is a catch-22. If we delay this, then necessarily the timeline for Electron app support also slips.

And as for "standards", we do have our own powerhouse: Red Hat Enterprise Linux. RHEL Workstation will eventually support this, and that will drive adoption too.

I encourage Fedora Workstation to not use their users as technological leverage for an API that might never be.

The API is coming. See #264, and I expect GNOME and KDE folks to come together to get it in shape and implemented. Having both desktops agree on a standard will be a huge driver for adoption.

Seems like this ticket has been effectively replaced by #264. If I'm wrong, feel free to reopen.

Due to #264 continuing to be stalled, I'm reopening this for consideration for Fedora Linux 38.

It would be great if this was finally solved. It's not (just) about AppIndicators, but about handling of background apps as such. There are multiple problems with background apps in Fedora (stock GNOME) making the experience much worse for regular end-users using such apps without the AppIndicator extension enabled.

Due to #264 continuing to be stalled, I'm reopening this for consideration for Fedora Linux 38.

It's worth pointing out that the GNOME App Indicator will not be released supported before 2027 (Ubuntu LTS 2022 EOL). Implementing a new API takes a long time, and it takes an ever longer time for all major platforms and toolkits to migrate. See my earlier posts, since I don't really have anything new to add in that regard.

There is another way of fixing this problem btw; Users of applications like Slack, Chrome and Edge, can ask their vendors to add a dependency for the current app-indicator.

Recommends: (gnome-shell-extension-appindicator if gnome-shell)

• https://pkgs.rpmfusion.org/cgit/nonfree/steam.git/commit/?id=6dad1a5b13ff14728bdefc73a653b58a9e3ccf4b

This will prompt applications like Slack to automatically download the necessary App Indicator components, helping their users on RHEL or Fedora Workstation. On Ubuntu based distributions this is of course not a problem, since Ubuntu has support for this de-facto standard, but I digress.

Anyway, this issue will remain relevant and I will not be surprised if the Ubuntu 24.04 LTS deadline slips, meaning that this issue will be kicked down the line another two years.

There is another way of fixing this problem btw; Users of applications like Slack, Chrome and Edge, can ask their vendors to add a dependency for the current app-indicator.

This will not resolve the issue for Flatpak / AppImage apps. Also, the gnome-shell-extension-appindicator does not get automatically enabled after the installation.

To enable it, you also need to run this command:
gnome-extensions enable appindicatorsupport@rgcjonas.gmail.com

Due to #264 continuing to be stalled, I'm reopening this for consideration for Fedora Linux 38.

It's worth pointing out that the GNOME App Indicator will not be released supported before 2027 (Ubuntu LTS 2022 EOL). Implementing a new API takes a long time, and it takes an ever longer time for all major platforms and toolkits to migrate. See my earlier posts, since I don't really have anything new to add in that regard.

Electron supports the standard through the libappindicator library. Changing the library to support a new standard would make those applications automatically support it. What you're talking about doesn't matter because we can just change the library it loads, as long as we preserve ABI (which we would).

My vote is -1 to adding the existing appindicator extension. We have upstream designs to support status notifiers finally, so it makes sense to pursue this upstream for now. Fedora users have had no status notifiers for a very long time, and I see no need to rush.

#264 remains on my to-do list, but any additional help to get it done sooner would of course welcome.

I think that instead of rejecting this now, it would be a better idea to postpone the milestone to F39 or F40 to give the upstream some time to finalize/implement the status notifiers and/or background apps support. Sure, Fedora users had no status notifiers for a long time, but it always degraded the user experience for many, many users (including myself) who use Steam, Telegram, Dropbox, Electron apps and other applications running on background.

We're going to eventually succeed here (because the most difficult problem -- upstream GNOME design -- is already solved) so at this point it's just a matter of when. This has been assigned to me, but it's not my top priority currently.

I've no intention of closing this issue before we have status notifiers working.

Adding status notifiers to the top bar now and then removing them from the top bar in a release or two will be disruptive. It's better to take our time and implement the desired design from the beginning rather than rushing things and starting with a temporary solution.

What is the design?

This mockup from this ticket. There Telegram is using a status notifier. The other apps are all using the background portal. The menu that's displayed there is for the background portal; menus for the status notifier would of course show the menu items that the app creates.

Notably it's much less prominent than it would be in the top bar, to avoid apps from trying to use the status notifier to steal user attention, but it does allow users to interact normally with the app when desired.

Er, we have two issues here that are very very similar to each other. Let's keep just #264 open.

I know Neal wanted to add an extension to support the status notifiers immediately while development on #264 continues, but I don't support that plan.

It seems issue linking is broken. Here is the other issue: https://pagure.io/fedora-workstation/issue/264

I'm keeping this open for the time being, because #264 hasn't moved forward yet.

The latest example: Podman Desktop:

"Manage Podman and other container engines from a single UI and tray."

Nothing has happened on #264 still, so I'm re-proposing that we ship the appindicator extension for Fedora Workstation 39.

A new spec will not be adopted if we offer compatibility with existing applications that depend on the old broken spec, so the path forward is to create something new and better, as part of GNOME upstream, hope applications will adopt it if they wish to be compatible with GNOME, and try to convince Ubuntu to drop their existing extension in order to nudge apps to upgrade.

This is a risky strategy because the Linux community does not have Apple's heft with developers. Dropping the existing extension before apps have migrated will break users' applications. The purpose of any platform is to run applications. If their apps stop working, users will simply go elsewhere.

@casey128 That's the same point that I make over two years ago, and repeated 5 months ago.

Sadly, the Fedora Workstation group (who coincidentally has a lot of core GNOME contributors) does not care and repeating the argument won't really sway anybody. As it stand now, the new upstream API will likely also miss the Ubuntu 24.04 LTS release which will mean that Fedora Workstation will not have app indicators before 2029.

This is an issue tracker, not a forum. Please stop the chit chat.

The workstation working group discussed this issue during its call yesterday. We agreed that the main obstacles to finishing the new API are:

1. Reaching agreement on the API design amongst the main stakeholders (limiting factors being having everyone's attention, and noise in the issue trackers)
2. Developer time

A hackfest with participants from GNOME, KDE and Budgie seems like the best path forward. We're investigating ways to make an in-person event happen. If that doesn't work out, we'll try and go for a virtual event instead.

We've agreed to discuss this again in 1 month, which will be the call on 17 October.

Current status is Tomas is trying to organize this hackfest around FOSDEM.

FOSDEM

FOSDEM 2024 ended February 4. Is there any news?

We called off the hackfest because we had only three confirmed attendees, and all were Americans. It didn't make sense for us to fly to Europe when we could meet in the US instead. It hasn't been rescheduled yet.

(A hackfest isn't truly necessary, but I thought it would be a good idea because there has thus far been nobody very motivated in working on this. If a motivated contributor were to take charge then we probably wouldn't need the hackfest.)

Hello there, I thought I'd finally make a significant contribution to this discussion, to hopefully revitalise it and ultimately get it actually truly going somewhere.

I meant to make this a few months back, but never had the time, so this has been a shower thought for a while now, but with recent GNOME mockups coming it gave me the push I need to finally share my own ideas, and so:

The following image is a mockup I made to extend Background Applications, and introduce a series of other standards, to fully replace the common feature sets of Application Indicators, all in a way where it can match both GNOME's paradigm and traditional paradigms of other Desktop Environments.

I'm going to split this mockup up later, into the respective Desktop Environments, and try to put the split up versions on Whiteboard and KDE VDG respectively, but for now I need to sleep, so... in the meantime, I really hope this can revitalise discussion about what DEs need to hopefully finally get implementations existing.

If the preview doesn't work, click on the image for the mockup.

@thatlinuxdude Interesting mockup, however the main problem in my opinion is that the current Background Apps implementation only supports Flatpak apps. No regular packages or, for example, AppImages.

Mockups are not required to reflect reality. It's perfectly fine to show things that are not possible, that's largely the point of them.

Next step for that mockup would indeed be to split it into separate GNOME and KDE designs. Then submit them to the upstream designers, because this ticket is too far removed from where design work occurs. For GNOME I would post it in this ticket (unless Allan asks you to post it somewhere else).

Next step for that mockup would indeed be to split it into separate GNOME and KDE designs. Then submit them to the upstream designers, because this ticket is too far removed from where design work occurs. For GNOME I would post it in this ticket (unless Allan asks you to post it somewhere else).

That's seriously helpful, thanks! I literally posted it here ahead of time to try and revive discussion here, and was already planning to get it split up into KDE Plasma and GNOME mockups on Friday, before putting it on Whiteboard for GNOME, so having you point me to the better page for GNOME eyeballing is really helpful.

As it stands right now, I dropped the merged mockup into KDE VDG already, as I know they're considerably more lenient with mockup contents, and there's been a bit of discussion in there about both my mockup and GNOME's "redux" mockup.

I personally think it's helpful to have mockups for cross-DE things with multiple desktops. It forces everyone to look at the impact of their choices for other people, rather than considering them in isolation.

For transparency reasons, I updated the mockup, both from Plasma feedback and some of my own identified loose ends, since and here it is:

Also sent it on the GNOME issue... 🤞