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
On Tue, Dec 3, 2019 at 12:40 AM Kevin Kofler <kkofler@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
