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