Status indicators

[cschramm]

This is a follow-up to #1362 (comment).

Linux tray icons / status indicators / whatever you want to call them are a mess. I'm trying to collect what I think to know about that mess.

There are basically two common ways to implement them: The old XEmbed protocol based on X11 and the newer StatusNotifierItem (SNI) based on DBus.

The two indicator implementations that blueman currently provides are based on GtkStatusIcon and libappindicator. GtkStatusIcon is a nice XEmbed implementation. GTK 4 will drop it (we could still use GTK+ 3 GtkStatusIcon, though, as blueman-tray is a small, mostly decoupled, standalone application now). libappindicator is an unmaintained piece of legacy software that has a bad SNI implementation and a bad fallback XEmbed implementation and evolved into some kind of industry standard for (non-Qt, non-kdelibs) SNI clients 🤦‍♂️. There's also Ayatana Indicators which is said to a be drop-in replacement for libappindicator although it's not and it does not seem more advanced than libappindicator itself. 🤷‍♂️ It does have some adoption though, at least in Debian (see #1217) and MATE (see mate-indicator-applet).

As XEmbed is tightly coupled to X11 and Wayland is a thing nowadays, mainstream desktops started dropping support for it. KDE, who initially drafted SNI for Plasma 4, dropped support in Plasma 5 (there is an xembed-sni-proxy thingy since 5.5, though). Ubuntu picked up KDE's SNI protocol to build Application Indicator (and the infamous libappindicator) on it and dropped XEmbed support in Unity. Let's not talk about Gnome Shell when it comes to trays...

Instead, let's turn to our target group where it's rather a question of who does not yet support SNI than of who does not support XEmbed (anymore):

• xfce4-panel: xfce4-indicator-plugin since like forever (4.4?), xfce4-statusnotifier-plugin since 1.14
• mate-panel: Builtin support since 1.18 / 1.20, also mate-indicator-applet
• lxqt-panel: plugin-statusnotifier since 0.10.0
• Cinnamon since 2.8
• LXPanel: Doesn't seem like it has support (is LXDE still relevant, though?)
• Budgie: There is budgie-indicator-applet, kinda third-party
• i3: No
• Sway: SNI only

Two things that bug me in libappindicator are the missing activate action (present in the SNI spec) and unclear markup support (see e.g. https://bugs.launchpad.net/indicator-application/+bug/522149; while the SNI spec has a tooltip property with well-defined markup support, libappindicator uses only the title property and implementations historically add some markup support / cleanup there).

@bentzys: Thanks for trying my test script on Plasma. It's sobering that it did not show you any text. I guess my implementation is not complete enough and will have another look / thought.

@infirit: Your questions should be answered by the above novel. 😅

[infirit]

It does mostly :-). I have been using xfce4-statusnotifier-plugin and it works well for blueman's appindicator.

So basically watch for the sni dbus name, if found load the sni implementation, if not fallback to a GtkStatusIcon. Would it make sense to leave the appindicator implementation in place but make the sni default with fallback to GtkStatusIcon?

[cschramm]

Would it make sense to leave the appindicator implementation in place but make the sni default with fallback to GtkStatusIcon?

I don't think it makes sense as that's exactly what libappindicator does (its fallback XEmbed implementation is GtkStatusIcon).

I was thinking about a pure DBus (as there seem to be no good and well-adopted libraries) SNI indicator implementation and changing the way blueman-tray selects the implementation from a single name to a list where it does trial and error, i.e. if the SNI plugin is enabled in blueman-applet, that list will be ["SNI", "GtkStatusIcon"] and if the SNI implementation signals that it cannot do it's job, blueman-tray falls back to the GtkStatusIcon one and gets a better icon than it would with the libappindicator fallback (an activate callback that is not just wired to the popup-menu callback, tooltip-markup instead of just title, ...). (An own SNI implementation would have the same main benefits over using libappindicator: Using the ToolTip property instead of just Title and provide an Activate method.)

I don't know how well the ToolTip property is supported by StatusNotifierHosts, though, and am disappointed that my snippet did not show anything in Plasma (although I even set Title and ToolTip). 😞 My guess is that it tries to use ToolTip but is not happy with the values I provide. I will try again when I find some time.

[cschramm]

Fixed the tooltip in my gist. @bentzys, could you try https://gist.github.com/cschramm/c6cc7cea909d7a40e6f5a976dbaf484f again, please?

[bentzys]

APYR:

[cschramm]

Nice. That does not look very bold to me but at least it does not show the tags. 🙂 I'll draft a DBus SNI indicator implementation and the mentioned trial and error mechanism for our tray then.

[infirit]

I ran the script and it looks not bold but otherwise fine with xfce-statusnotifier-plugin

[bentzys]

FYI: I can not see any bold text at any of my system tray icons tooltips, The second line is always grayed and font is smaller...

[cschramm]

There's a draft in #1382. It only implements the necessary bits of the SNI interface as I'm unsure how much sense it makes to stick to the standard if already the interface name deviates in reality.

Compared to the AppIndicator implementation we gain a primary action and a working tooltip (even with support for our bold text at least in mate-panel). Compared to the GtkStatusIcon implementation we lose formatted menu item labels (the PowerManager's menu item) as Canonical DBus menus just do not support it (see https://bazaar.launchpad.net/~dbusmenu-team/libdbusmenu/trunk.16.10/view/head:/libdbusmenu-gtk/parser.c#L590).

The draft uses category Hardware which seems more appropriate to me than ApplicationStatus used by our AppIndicator implementation, so the icon's location differs for me.

[eliaz051]

Missing information, but very useful for Bluetooth devices in Blueman, to have the remaining battery level in graph and percentage form.
(like on Android).