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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to desktop-leave(a)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...