Thanks, that’s clearer. I’m not a developer either. Last I read, it was for applications to send their icon and their menu to the system. The UX is managed by the platform.
Just to clarify, I am an app developer familiar with these APIs but I am not a GNOME developer. The mockup for “background apps” seems to be a proposal for a GUI around the background portal, which is another API that already exists. The app indicator API does not need to be updated in order for the background portal to work, actually app indicators are not involved there at all.
The most concrete goal I have seen for updating the app indicator API is to make non-GTK apps (i.e. Electron apps and KDE apps) work more like they are using panels on other platforms, but I am doubtful there will be any benefit there. The Electron API seems to mimic Windows and is already losing a lot of functionality even on Ubuntu or KDE due to the app indicator API not matching Windows. For GNOME apps there is no benefit at all, the GNOME solution to panel applets is to use extensions so any work on app indicators is a worse duplication of that functionality. And the KDE API also seems to have some KDE-specific javascript functionality so that will not work either.
Look at the mockup text, it’s also for app indicators (even though it’s under the “Background Portal” heading).
Also, for the background portal: https://github.com/flatpak/xdg-desktop-portal/pull/901.
The reasons for a new specification are mentioned at the beginning of Update StatusNotifierItem/systemtray spec (#84) · Issues · xdg / xdg-specs · GitLab.
You can also read this new spec if you haven’t already: Draft: Add draft for status-icon-spec (!54) · Merge requests · xdg / xdg-specs · GitLab
Your link for KDE talks about widgets, which has nothing to do with application indicators…
Yes, as I said before, there is significant overlap with app indicators and what the background portal already does. You can call it by the name “app indicators” but in the code it is something different.
That is implementing the status message which can be used as part of an implementation for that mockup. It is useful even without a full new GUI. I already talked about this a while ago, the status message is preferable to app indicators and mostly replaces them. App indicators only really know about icons. Unless you are using KDE where they can show multiple icons and also animations…
I am not sure if I have communicated this correctly. There are no real compelling reasons there. It says the old spec is obsolete (which it is) due to some technical reasons but it does not talk about all the other major UX problems with the spec that cannot be fixed by just adding sandboxing, nor does it talk about any of the practical issues in getting GNOME, Ubuntu and KDE to all use this correctly when they all have conflicting requirements. The discussion goes off into many other things and circles around various re-implementations of panel applet functionality. I do not expect it to go anywhere else, because that is ultimately the only thing app indicators really do.
Well I just mentioned I read that already. That spec does not solve any of the issues I mentioned in my first reply in this topic. And it also adds little of value to the “background apps” mockup, nearly all functionality there is provided with other APIs.
No, in KDE the app indicator space is called “system tray” and it can contain widgets. Technically the GNOME Shell top panel can also contain widgets if an extension adds them, that is how the app indicator extension works.
Something I forgot to mention. The main reason to update the app indicator API is to give older apps an upgrade path to a newer API. But since any update to app indicators is going to suffer from the same issues, they are not gaining much by doing that. For backwards compatibility it would be better to re-implement app indicators in terms of the background and notifications portals and add whatever bits needed as a compatibility measure. Because it is not possible to recompile every old binary, it would have to be a D-Bus service run by the sandbox that does the conversion. GNOME apps do not use this pattern, and KDE has their own spec, so really Electron and other things using libappindicator is all that matters here. Sorry if I sound pessimistic but this is my conclusion after reading through all these discussions and seeing this brought up multiple times over many years. Nothing is really different this time, the API and UX is still just fundamentally unworkable and you can see that in the way the discussion always trails off into bikeshedding. If the extension works for you, then great, but I think that is all you can ask for. I hope someday I am wrong and some consensus gets reached, I would not advise anyone to get their expectations up.
While I agree that app indicators (if implemented in the system tray) are not much accessible and have other problems, they are still better suitable for background applications than persistent notifications, at least in my opinion (and the biggest problems with accessibility are resolved in this design). We had persistent notifications for many years now, almost no apps use them and majority of GNOME users still miss proper background apps support.
The new app indicator spec is all about having a standard and modern way for cross-platform apps. Maybe it can be complementary to what the platforms offer for their own apps?
Moreover, I think app indicator support is mostly used in GNOME for legacy purposes and for proprietary apps. GNOME apps are not expected to use this new specification. Only developers of apps with UI for GNOME and wanting support on other platforms should use it.
Also, I don’t agree with such UI (and therefore UX). You can read my opinion and alternative proposal on the “Background apps design” issue that I linked (proposal that I will revise).
Since the only thing that really matters for cross-platform is the Electron API (and maybe the Win32 API exposed from WINE) this will be inadequate as it still does not match the capabilities of that API. And it cannot really do that without going against the design of both GNOME and KDE. Developers wanting to create a UI for GNOME will just not use any app indicator API. A spec only matters so far as you are creating multiple implementations, which I do not actually see happening here. If all that is needed is a wrapper around some other API then that can just live in Electron and they can remove libappindicator.
It is to be expected that not everyone agrees with the UX so that is why I say just use extensions as you are doing now. I imagine at least some of those proposals to get turned into extensions just because they usually do anyway.
Sorry for the confusion. By cross-platform, I meant the different desktop environments on Linux distributions. For example, KDE can use its specs for its own apps (with effects, changing icons, etc.) while providing app indicator support for display in GNOME. But notifications are still the means of announcing status changes. Ditto for GNOME applications if desired by the developers.
I’m also a bit confused as to what you mean by UX… What do you mean by that?
I think I mentioned that, the background portal already covers the common bits. For the KDE extensions, no new spec is needed. Those stay in KDE.
The UX refers to the whole user interaction with the entire system, versus the UI which only refers to the arrangement and behavior of the buttons and menus and labels, etc.
Ok. I re-read a bit. Anyway, I’m not for it and if they agree on something, I hope in the future that there will be developments around some of the things I proposed.
I fully agree with AsciiWolf on this. It is frustrating to miss events occurring in the desktop environment because there is no way to know an app awaits attention from the user if that app’s window is not visible in the foreground.
The example I mention in my original post of this thread is one of the most important in a workplace context. Office chat and collaboration tools (like Slack, Teams, and others) use indicators to tell the user they have messages waiting or other items that require their attention. When we can’t see those things, messages or other requests go unattended for longer than they should be, inhibiting and slowing down the flow of communication and work.
These sorts of things are important in order for Gnome to be considered a serious tool for business.
If Gnome designers remain adamantly against status indicators in a tray-like area, perhaps a compromise is possible, where status indicators can appear over items in the dash. Then users can employ a Gnome plug-in like Dash to Dock to see them there.
Really, I’m not picky about how it is done, myself. I just need some way to see at a glance that I have messages waiting for me – without manually checking each application or by clicking the Gnome notification area. That could be through something in a tray, the dash, or some other feature. 
That is what notifications are for. I think there is a common misunderstanding that GNOME does not have an API for this, the notification API already exists and fulfills that purpose. Perhaps you can make a request to have the UI around it changed, to make some notifications more prominent.
I think that would help, but it would not completely address the need I’ve raised.
The problem is that if one misses a notification, there is no way to see that an app has a status requiring their attention. For me, I often (but not always) see the notifications when I am looking at my screen. Other times, I may be busy with another task, and can’t address the notification in the moment – I need it to persist in some way until I’ve addressed it. So I really need notifications or status indicators that remain on-screen. The typical status indicators in the tray (like those for Slack and Teams, to call on that example again) are very effective for this – they are discreet enough such that they do not disrupt my work-flow, yet clear enough, and I know to glance to the corner of my screen occasionally to see if anything requires my attention.
That is already supported, that is what “resident” notifications are for along with the notification priorities. A high priority resident notification should stay until it is dismissed by the user.
I guess the notification counter didn’t help you. I tested and its number is limited to 10…
Status indicators are not in the top bar due to the mobile interface where there is not much space. However, as Jason Francis said, your problem is with notifications and not status indicators.
You can request to “have a persistent visual indicator in the top bar for specific app notifications” at Gnome-Shell − New Issue. Select the “Feature” template. Give them a summary of what you want and describe your use case/problem.
No. We haven’t put status icons in the top bar since GNOME 3.0 more than a decade ago, many years before anyone considered running gnome-shell on a mobile device.
This blog post includes the rationale (“system vs application”).
To me, the image there really drives the point home immediately about the issues with app indicators:
Are any of those icons signaling there are notifications available? I cannot tell just by looking at them. I just see a bunch of random icons that may be communicating that some apps are in some indeterminate state. This is why the older spec had “balloon messages” but those were replaced with notifications, so I hope people can see why it makes even less sense to use app indicators now.
I’m talking about their reintroduction and on why they aren’t in the top bar 
“The top bar is a system area, and apps are separate from that” is still a stronger reason than mobile.