#246 Supporting status notifiers in Fedora Workstation by default
Opened 2 months ago by ngompa. Modified 22 days ago

Over the course of comparing experiences at work with Ubuntu, Fedora Workstation, and Fedora KDE, I've discovered that the lack of status notifier support in Fedora Workstation out of the box leads to too many situations where people think applications aren't functioning properly.

At least in my case, the lack of status notifier items means the following:

  • I cannot access my corporate VPN app (Palo Alto GlobalProtect) at all since it is entirely orchestrated through the status notifier icon
  • I cannot access Dropbox at all since the app is entirely orchestrated through the status notifier icon
  • I cannot always fully quit Steam, since the application control is in the status notifier icon
  • My corporate password manager (1Password) provides certain actions through the status notifier (locking the password manager, for example).

There is an incomplete list of applications with reduced or broken functionality without some status notifier item support on the GNOME wiki.

Today, the preferred extension in the GNOME 40+ world is the appindicator-support extension, which is packaged in Fedora as gnome-shell-extension-appindicator. It replaced TopIcons Plus, which was abandoned with GNOME 40.

I would like to propose we preload this extension as a short-term fix, but move toward a model like so in GNOME:

  • Status notifiers are hidden away in a drop-down instead of directly allocated on the the top menu (this is essentially the default for KDE Plasma and Windows now). This avoids the "free branding real-estate" issue that @mclasen brought up in the past.
  • XEmbed support is deliberately excluded, and SNI/appindicator support is restricted to what the appindicator extension permits. This eliminates the "legacy trap" of forcing us to support X stuff forever.

The reality is that more applications are getting built to use status notifier items than ever before, especially Electron apps where it's a common pattern. I would like Fedora Workstation to be more usable and useful out of the box for everyone, and I really do think this is an important aspect that we need to address to support the wide swath of applications out there.


+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.

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.

Metadata Update from @ngompa:
- Issue tagged with: experience

2 months ago

+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.

Metadata Update from @ngompa:
- Issue set to the milestone: Fedora 36

2 months ago

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.

Metadata Update from @ngompa:
- Issue untagged with: meeting

a month ago

Metadata Update from @ngompa:
- Issue tagged with: meeting-request

a month ago

Metadata Update from @ngompa:
- Issue untagged with: meeting-request

a month ago

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.

  • 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.

Metadata Update from @catanzaro:
- Issue tagged with: meeting-request

22 days ago

@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.

Login to comment on this ticket.

Metadata
Attachments 1