Hello,
I would like to propose a RFE for Fedora Workstation. I think what Fedora Workstation, or GNOME in general, really misses is some support for tray icons. There are many applications that do not work properly when having no tray icon. Nowadays, tray icons are mostly implemented using an AppIndicator standard made by Canonical and supported in GNOME using the "KStatusNotifierItem/AppIndicator Support" Shell Extension also made by Canonical and packaged in Fedora as gnome-shell-extension-appindicator. This extension is preinstalled out-of-box in Ubuntu. In KDE, AppIndicators are supported out-of-box.
Is there a place I could send a RFE to add the gnome-shell-extension-appindicator package to base Fedora Workstation installation or is this e-mail sufficient? No out-of-box support for tray icons is a big minus for Fedora in my opinion.
Thanks!
Regards, Daniel Rusek
Hi Daniel,
Although I agree that we should support tray icons out-of-the-box, I'd rather do this in a way that would be upstreamable so that we don't wind up requiring a shell extension to make this work. AppIndicator has been rejected from GNOME due to serious technical problems [1], so that particular approach seems to be a dead end and probably not useful to focus on. And adding support for AppIndicator now would likely pose backwards-compatibility issues in the future, given that any upstream implementation of tray icons is likely to be incompatible.
The GNOME design team has previously expressed willingness to explore designs for tray icons, and I think GNOME community has a rough consensus that some form of tray icons would be desirable (see the most recent discussion at [2]), but I don't think there are any designs yet. I think we're a bit stuck on coordination problems right now: nobody is quite sure what this would look like, and nobody is working on it. So I think the place to start would be to take this upstream to the GNOME community and try to work out something that could be adopted everywhere, rather than as a shell extension.
Thanks for your interest,
Michael
[1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/1014#note_568908 [2] https://mail.gnome.org/archives/desktop-devel-list/2019-March/msg00020.html
Hi Michael,
you mean like this last discussion [0], that was labeled Out of Scope?
Michal
[0] - https://gitlab.gnome.org/GNOME/gnome-shell/issues/1014
On 2019-11-27 21:18, Michael Catanzaro wrote:
Hi Daniel,
Although I agree that we should support tray icons out-of-the-box, I'd rather do this in a way that would be upstreamable so that we don't wind up requiring a shell extension to make this work. AppIndicator has been rejected from GNOME due to serious technical problems [1], so that particular approach seems to be a dead end and probably not useful to focus on. And adding support for AppIndicator now would likely pose backwards-compatibility issues in the future, given that any upstream implementation of tray icons is likely to be incompatible.
The GNOME design team has previously expressed willingness to explore designs for tray icons, and I think GNOME community has a rough consensus that some form of tray icons would be desirable (see the most recent discussion at [2]), but I don't think there are any designs yet. I think we're a bit stuck on coordination problems right now: nobody is quite sure what this would look like, and nobody is working on it. So I think the place to start would be to take this upstream to the GNOME community and try to work out something that could be adopted everywhere, rather than as a shell extension.
Thanks for your interest,
Michael
[1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/1014#note_568908 [2] https://mail.gnome.org/archives/desktop-devel-list/2019-March/msg00020.html
desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
On Thu, Nov 28, 2019 at 2:10 pm, Michal Konecny mkonecny@redhat.com wrote:
you mean like this last discussion [0], that was labeled Out of Scope?
Hi,
Yes, that's the same discussion I linked to in my previous mail. AppIndicators (as specified by the AppIndicator specification) are considered out of scope. But community interest in developing some sort of replacement for tray icons seems pretty clear.
Michael
Michael Catanzaro wrote:
Although I agree that we should support tray icons out-of-the-box, I'd rather do this in a way that would be upstreamable so that we don't wind up requiring a shell extension to make this work. AppIndicator has been rejected from GNOME due to serious technical problems [1], so that particular approach seems to be a dead end and probably not useful to focus on. And adding support for AppIndicator now would likely pose backwards-compatibility issues in the future, given that any upstream implementation of tray icons is likely to be incompatible.
The thing is, what you call "AppIndicator" is actually the cross-desktop Status Notifier Icon (SNI) spec that has been adopted by all other desktop environments out there, and even by a GNOME Shell extension that is already packaged for Fedora and that you would just have to ship. ("AppIndicator" is just Canonical's marketing name for SNI.) GNOME is late to the party and as such does not have the luxury of setting its own spec.
It is really absurd that you are bringing up compatibility as an argument for not implementing the spec that everyone else uses and waiting for a hypothetical incompatible spec instead. To support third party applications, there is no other way than implementing the existing SNI spec. And GTK+ applications also need to implement the SNI spec instead of the legacy XEmbed spec that is a PITA for other desktops to support (see the xembedsniproxy hack that KDE Plasma ships) and does not work natively under Wayland. (Several GTK+ applications can be optionally built with libappindicator support and Fedora is the one distribution that refuses to do that.)
As for the "serious technical problems", it looks like the main issue is that GNOME does not want to implement the cross-desktop dbus-menu spec and wants to force everybody to implement its proprietary GMenu spec instead, which is not going to happen. I have to say it again: GNOME is late to the party and as such can only either implement what everyone else already uses or just not work. There is no third option. And it is entirely unrealistic to expect other toolkits to switch from the toolkit-agnostic dbus-menu spec to a spec designed for GTK+'s GMenu only.
The GNOME design team has previously expressed willingness to explore designs for tray icons, and I think GNOME community has a rough consensus that some form of tray icons would be desirable (see the most recent discussion at [2]), but I don't think there are any designs yet.
This is funny because so far the mantra had been that tray icons are incompatible with GNOME Shell's design and that developers should use persistent notifications instead. (Of course, the existence of the TopIcons and AppIndicator extensions proves that that argument never made any sense. So it is good news that the consensus has changed, but not that GNOME wants to reinvent the wheel with an incompatible spec.)
On Mon, Dec 2, 2019 at 11:39 pm, Kevin Kofler kkofler@fedoraproject.org wrote:
I have to say it again: GNOME is late to the party and as such can only either implement what everyone else already uses or just not work.
Well you're right, but "just not work" is going to be the answer. Supporting the existing spec is too controversial -- I see almost no chance of this happening -- and that means that whatever gets implemented will have no backwards-compatibility for existing apps. I think accepting this is the only way to advance design and discussion for actually implementing a system tray (or comparable functionality); otherwise we'll remain stuck in a stalemate arguing over the spec.
Anyway, it's not something that's going to be advanced by the Fedora project on Fedora mailing lists. Fedora is good at pushing forward many things, but discussions like this need to happen upstream to be effective. (And we have to get it accepted by Ubuntu too, or whatever we do will fail, because as long as Ubuntu continues to support AppIndicator, apps will continue using it regardless of what we do.)
Michael
Hmm, you are right about the SNI specification. I was not aware that it is actually an open standard with a site hosted on Freedesktop.org[1]. Nice!
Daniel
[1] https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/
On Tue, Dec 3, 2019 at 12:40 AM Kevin Kofler kkofler@fedoraproject.org wrote:
Michael Catanzaro wrote:
Although I agree that we should support tray icons out-of-the-box, I'd rather do this in a way that would be upstreamable so that we don't wind up requiring a shell extension to make this work. AppIndicator has been rejected from GNOME due to serious technical problems [1], so that particular approach seems to be a dead end and probably not useful to focus on. And adding support for AppIndicator now would likely pose backwards-compatibility issues in the future, given that any upstream implementation of tray icons is likely to be incompatible.
The thing is, what you call "AppIndicator" is actually the cross-desktop Status Notifier Icon (SNI) spec that has been adopted by all other desktop environments out there, and even by a GNOME Shell extension that is already packaged for Fedora and that you would just have to ship. ("AppIndicator" is just Canonical's marketing name for SNI.) GNOME is late to the party and as such does not have the luxury of setting its own spec.
It is really absurd that you are bringing up compatibility as an argument for not implementing the spec that everyone else uses and waiting for a hypothetical incompatible spec instead. To support third party applications, there is no other way than implementing the existing SNI spec. And GTK+ applications also need to implement the SNI spec instead of the legacy XEmbed spec that is a PITA for other desktops to support (see the xembedsniproxy hack that KDE Plasma ships) and does not work natively under Wayland. (Several GTK+ applications can be optionally built with libappindicator support and Fedora is the one distribution that refuses to do that.)
As for the "serious technical problems", it looks like the main issue is that GNOME does not want to implement the cross-desktop dbus-menu spec and wants to force everybody to implement its proprietary GMenu spec instead, which is not going to happen. I have to say it again: GNOME is late to the party and as such can only either implement what everyone else already uses or just not work. There is no third option. And it is entirely unrealistic to expect other toolkits to switch from the toolkit-agnostic dbus-menu spec to a spec designed for GTK+'s GMenu only.
The GNOME design team has previously expressed willingness to explore designs for tray icons, and I think GNOME community has a rough consensus that some form of tray icons would be desirable (see the most recent discussion at [2]), but I don't think there are any designs yet.
This is funny because so far the mantra had been that tray icons are incompatible with GNOME Shell's design and that developers should use persistent notifications instead. (Of course, the existence of the TopIcons and AppIndicator extensions proves that that argument never made any sense. So it is good news that the consensus has changed, but not that GNOME wants to reinvent the wheel with an incompatible spec.) _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
On Wed, Dec 4, 2019 at 5:24 PM Daniel Rusek drusek@redhat.com wrote:
Hmm, you are right about the SNI specification. I was not aware that it is actually an open standard with a site hosted on Freedesktop.org[1]. Nice!
It was proposed on freedesktop where GNOME folks provided feedback (for example [0]).
The response to any issues raised (except for typos) boiled down to:
"Too bad, we're not going to change this. Take it or leave it".
Which we did.
And considering that the "standard" is still just the rejected draft, I don't see a reason to change the answer to anything different than "leave it".
Florian
[0] https://lists.freedesktop.org/archives/xdg/2010-January/011228.html
On Wed, Dec 4, 2019 at 3:20 PM Florian Müllner fmuellner@gnome.org wrote:
On Wed, Dec 4, 2019 at 5:24 PM Daniel Rusek drusek@redhat.com wrote:
Hmm, you are right about the SNI specification. I was not aware that it is actually an open standard with a site hosted on Freedesktop.org[1]. Nice!
It was proposed on freedesktop where GNOME folks provided feedback (for example [0]).
The response to any issues raised (except for typos) boiled down to:
"Too bad, we're not going to change this. Take it or leave it".
Which we did.
And considering that the "standard" is still just the rejected draft, I don't see a reason to change the answer to anything different than "leave it".
Well, if GNOME isn't going to play ball, we can just ship the extensions by default in Workstation, ne? I see absolutely no reason to hurt our users with the bickering between GNOME and the rest of the desktop Linux community. Ubuntu is also already shipping an extension by default, and quite frankly, I'm surprised we haven't yet.
On 04/12/2019 22:26, Neal Gompa wrote:
On Wed, Dec 4, 2019 at 3:20 PM Florian Müllner fmuellner@gnome.org wrote:
On Wed, Dec 4, 2019 at 5:24 PM Daniel Rusek drusek@redhat.com wrote:
Hmm, you are right about the SNI specification. I was not aware that it is actually an open standard with a site hosted on Freedesktop.org[1]. Nice!
It was proposed on freedesktop where GNOME folks provided feedback (for example [0]).
The response to any issues raised (except for typos) boiled down to:
"Too bad, we're not going to change this. Take it or leave it".
Which we did.
And considering that the "standard" is still just the rejected draft, I don't see a reason to change the answer to anything different than "leave it".
Well, if GNOME isn't going to play ball, we can just ship the extensions by default in Workstation, ne? I see absolutely no reason to hurt our users with the bickering between GNOME and the rest of the desktop Linux community. Ubuntu is also already shipping an extension by default, and quite frankly, I'm surprised we haven't yet.
It will be also nice to have the extension as part of the Silverblue ostree image.
desktop@lists.fedoraproject.org
-
Daniel Rusek -
Florian Müllner -
Kevin Kofler -
Michael Catanzaro -
Michal Konecny -
Neal Gompa