Re: I believe we should reconsider our sys-tray removal



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]