Persistent Status Indicators for Apps

tldr: How can I configure persistent status indicators for specific apps?

Hello! I would like to have a way to know when new messages are waiting for me in Teams (and other similar apps), which I use for work. I am using the new Teams progressive web app in Gnome 43 on Fedora 37.

At issue for this program and others is that I can’t see any indicators, which tell the user that there are unread messages or other yet-to-be-seen content. So if I miss a pop-up notification for a new message, I have no idea that there is one. This happens a lot, and my colleagues may be waiting some time before I manually check Teams to see that there are new messages waiting for me.

This same issue happens with other apps, like Slack, which also put notification icons in the desktop tray.

One can use an extension like “Tray Icons Reloaded” to display a tray, which works for Slack, but not the new Teams PWA, as this PWA does not put an icon in the tray at all – even if I try to force it to do so through the Tray Icons Reloaded configuration panel.

I searched this form and Gnome documentation (1, 2), and all the configuration options for Teams, Gnome, and my browser before posting, but did not find quite what I was looking for.

So, might anyone know what the “proper” Gnome way is to display such indicators, or something like them that serves the same purpose? I imagine there must be an official Gnome way of providing some sort of indicator like this to the user, given that Gnome does not natively support tray icons.

Thank you!

Hello Michela!

Considering the comments on Tray Icons: Reloaded - GNOME Shell Extensions, I suggest you to try the appindicator extension.

You can install it from the terminal with:

sudo dnf install gnome-shell-extension-appindicator

Remember to disable “Tray Icons Reloaded” to avoid conflicts.

In the future, GNOME desktop will officially support tray icons, but, as of latest news, these icons will be hidden (see Background apps design (#191) · Issues · Teams / Design / os-mockups · GitLab, the design is in Design/Background Portal section), which will not help you to directly see the number of messages.


Hi, Michaël! Thank you for your quick reply!!

The suggestion to use the ‘gnome-shell-extension-appindicator’ extension is a good one, as it does appear to be better than the one I was using before.

That does not solve my problem, however. No matter what I try, I still can not get an indicator icon to appear in the tray area. It appears what I would like is simply not possible at the moment.

Maybe I will be able to have an icon in the tray for my progressive web apps once that “background apps design” change you linked me to is implemented – it will be great to finally have this functionality in Gnome again! It is sorely missed. :smile:

Thanks again for your help, and have a fantastic weekend!


Are your PWAs apps flatpaked?

Forget my post about flatpak.

I installed official app and unofficial app from flathub. The official does not display anything (on Wayland; I can no longer log in to an Xorg session) but displays an indicator. The unofficial app shows an indicator but there is no setting to have a badge on the status bar icon (I can’t test to see if there is a badge because I have no discussion).

As for official support for background apps, also be aware that this does not mean that tray icons will support badges. I don’t even think the GNOME desktop will support badges. There was a discussion about status strings (text instead of badge) where it says the app can lie about its status. The other argument is that there are notifications to. notify the user of statuses. Therefore, this option would not be retained. Also, these icons will be so hidden that looking at them is definitely no more useful than looking at notifications.

So could you tell what the problem is with the notifications? In this way, these could be improved. Thanks!

Also have a fantastic weekend :wink:

Thank you for doing all that!!

Unfortunately, the Teams for Linux native desktop app is being discontinued and is no longer supported. :frowning: This new PWA is the official replacement for the Linux desktop app.

So I was hoping that I could somehow make the Teams PWA work in the same way as the native Linux desktop application, with a tray indicator.

Gnome notifications work great, and they also work well with Teams (PWA, web site, or native app). The problem is that if users are away from their desks, in a call, looking away from their screen, or do not see a notification at the moment it appears for any reason, they have no way of knowing at a glance that an application has a status that requires their attention. So in my case, I find that since switching to the new Teams PWA, I fairly often have messages from colleagues waiting for me when I bring the app to the foreground on my desktop. This makes for ineffective work-flow for me and my colleagues, and it is frustrating for people who are trying to reach me. So I’m trying to work out some way to have such status indicators display on screen at all times (or at least when the app requests attention).

I found this gnome-shell extension: Notification Counter - GNOME Shell Extensions

It shows the number of notifications you have. Maybe it can help you a little.

1 Like

Thank you for that! It appears that old notifications linger in Gnome’s notification area, even after the application that triggered them has been activated. I may try this plug-in to see if I can partially address my needs.

This plug-in (or something like it) looks like it might help me, particularly if the Teams PWA shows a badge when a message is waiting (hopefully, it does that – it’s hard to tell at the moment): Minimize to Tray - GNOME Shell Extensions

Do you want something like filters (just look at the notification part at the bottom): ?

For the Minimize to Tray extension, I don’t think it will work. The extension need to be compatible (if you have chance it is), and it seems only to create an icon to minimize apps (it will be not the indicator of Teams).

Personally, I have the indicator with the extension I recommended you and we have the same OS. So there is a problem. Did you install the extension from the fedora repo or from the extensions website? (due to AsciiWolf’s comment in AppIndicator and KStatusNotifierItem Support - GNOME Shell Extensions)

You’re right about the minimize to tray extension. I tried it shortly after my last post, and indeed, it is not compatible with Gnome 43.

I have been using the extension you recommended, and it is better for showing the icons in the tray than the one I was using before, but it still does not serve my purpose of putting an icon in the tray for an app of my choice (especially a PWA). I installed it with dnf, following the instructions on the extension’s project page you linked me to.

I think my next stop should be a Teams support forum. Hopefully, there is some Linux support for this application there. :smiley:

Thank you again, Michaël!!

1 Like

Better support for background applications and/or AppIndicators (tray icons) is the last remaining thing that I miss on GNOME. I am using the “AppIndicator and KStatusNotifierItem Support” Shell Extension (it is the only extension that I use), but a standard, out-of-box solution would be much better and would help make desktop Linux even more accessible to end users. :slight_smile:

1 Like

Hello, a major problem with app indicators is that they are actually not accessible and they reduce overall accessibility, their interaction model is poorly defined. The click targets are too small, and since they are just icons, it is unclear from an indicator what is actually being indicated. Notifications are much better for that purpose. It is also inconsistent whether an app indicator responds to left-clicking, or what it is supposed to do when it receives a left-click, or if it will show a menu or not. All of this is fairly mouse-centric and so it is mostly useless for keyboard users, they are better served by having good keyboard shortcuts. If you really want this, it can make sense to use an extension. With the current GNOME design I cannot ever see this becoming standard, it has too many issues. (Disclaimer: I am not a GNOME designer)

Support for app indicators is coming: Background apps design (#191) · Issues · Teams / Design / os-mockups · GitLab.

Those are background apps, not app indicators in the way the term is used in Ubuntu. It is not the same as what the app indicator extension does. And IMO it is a much better and more accessible UI/UX than app indicators. Also that seems to still be in the proposal stage, not a confirmed feature.

This UI is intended for apps using the App Indicator API, not just apps running in the background. App indicators are not tied to a specific UI.

The feature - having a UI to expose apps running in the background and those using the appindicator API - is confirmed somewhat. This is from at least 10 months ago: Application Status Notifier Design (#150) · Issues · Teams / Design / os-mockups · GitLab.

That still seems to be a proposal, nothing concrete. And the APIs for background apps and notifications already exist, no new API is needed there, aside from enhancements for persistent notifications.

If you are talking about the App Indicator API as it exists in libappindicator, IMO there is no reason for that ever to come back. The numerous problems I mentioned before are also present in the API, so I am pessimistic about anything actually happening there. It is not really possible to paper over a flawed API by making another UI. IMO when this is discussed there is a lot of confusion about what is actually being supported, the interaction model used by libappindicator is basically unworkable and I doubt those apps using that API will ever be able to fully behave correctly on various Linux environments.

See Update StatusNotifierItem/systemtray spec (#84) · Issues · xdg / xdg-specs · GitLab. That’s what Allan is referring to.

Also, at the end: Issue #264: Work on a new appindicator protocol - fedora-workstation -

If you want more information, just follow the links (and links within links). It can be (very) long to read, but you will have all the necessary information, the comments already made, and alternative UI and UX proposals.

I have read all those links months ago, and I think that ultimately all that is futile. The proposals will not work with the API as it stands and it is not possible to fix it by creating a new API. The reason those discussions are so long and wandering is because there is not actually any clear goal of what app indicators are supposed to be. They are in a strange UX spot in between notifications, panel applets, dash icons, and app menus. But they cannot really fulfill any of those goals well, due to in part to some of the problems I mentioned before. That is just my opinion though.