I agree with Britt. In Endless we currently ship an in-tree copy of TopIcons,
but this won't fly in a Wayland world, so we're considering what to do in
future.
On Mon, 25 Mar 2019, at 11:20, Emmanuele Bassi via desktop-devel-list wrote:
> Sadly, this means a complete API change, which makes the point moot:
> applications would need to be changed.
>
> […]
>
> The appindicator API/StatusNotifier specification comes close to this, but:
>
> - [… several major shortcomings …]
For another example off the top of my head, the spec at
https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/StatusNotifierItem/
says that apps should register a name of the form
“org.freedesktop.StatusNotifierItem-PID-ID”, which in a Flatpak world means
allowing the app to own any name in the “org.freedesktop.*” namespace.
On the other hand: this API under its various names is already widely-supported
both by (non-GNOME) apps, and by widely-used desktop environments – a virtuous
cycle. In particular, several third-party, non-free apps like Dropbox which are
partially or totally unusable without a status notifier already support it.
(Not to make this all about Dropbox – it's just an app I use that falls into
the "totally unusable" category.)
I'm sure it's not as simple as "copy
https://github.com/ubuntu/gnome-shell-extension-appindicator into the
gnome-shell tree" – though it seems to work fine after a few days' testing –
but supporting and improving this API would at least mean that many existing
apps would behave as intended by their developers without needing to be changed
(immediately).
>
>> Permanently adding the extension code to the shell (which, if I've
>> undesrtood properly, "moves" icons from tray to topbar) will be a dirty but
>> effective solution.
>
> Which would achieve nothing except, once again, shoving icons and menus into
> one of the most important pieces of screen real estate we have just because
> some application developers simply cannot live without their application
> icons being visible at all times. If you want to do that, use the extension.
> It's there for a reason.
The problem with the extension route is that it shifts the burden onto each
individual user (assuming app developers don't redesign their apps to remove
the indicators, which many haven't, and assuming distributors don't intervene
as described by Britt). If Shell supported indicators out of the box, then
there would be two cases:
1. user doesn't use any apps which show indicators: great, no junk on the
panel.
2. user does: their panel has some icons on it. (Ideally, some mechanism would
exist for them to be disabled just like Settings → Notifications.)
If there were a blessed extension, the two cases would be:
1. they don't use any apps which show indicators: great, no junk on the panel.
2. they do: these apps don't work properly. Each user has to independently
discover that an extension exists; they enable it and now their apps work.
The status quo is:
1. they don't use any apps which show indicators: great, no junk on the panel.
2. they do: these apps don't work properly. Each user has to independently
discover that many different extensions exist which purport to make their apps
work, decide which one to use, and enable it.
A blessed extension in gnome-shell-extensions would be an improvement but I
don't really see the advantage of not enabling it by default.
> The tray icons were designed and meant for system status notifications:
> network state connectivity, volume level, battery level, IM status (when it
> was a thing). They were hijacked by application developers to have panel
> applets that would work across desktop environments. It was a bad idea then,
> and nothing has changed in that regard.
I agree that status icon proliferation is a bad experience, but they exist and
apps rely on them being shown. Perhaps a design similar to what Chromium does
with extensions, where icons overflow into the hamburger menu, could be a
reasonable compromise.
– Will
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
