Linux Mint/Cinnamon doesn't support StatusNotifier tray icons standard

[p3x-robot]

Issue
Linux Mint/Cinnamon doesn't support StatusNotifier tray icons standard. So it's an upstream issue you might want to place in Mint/Chromium issues tracker.

electron/electron#21445 (comment)

Steps to reproduce
Since ELectron v8 the tray is not working because they switched to StatusNotifier .

Expected behaviour
Show tray.

[vladimiry]

According to https://bugs.archlinux.org/task/65483 StatusNotifier tray icons support implemented but it's not complete:

On Cinnamon it might help to toggle "System Settings" -> "General" -> "Enable support for indicators" (tested with Keybase)

When you say you tested it with Keybase... I get a systray icon, it just does nothing -- it doesn't bring up the popup in the corner of the window, and it doesn't provide a clickable menu to try doing this either.

Indeed, further testing shows that the Cinnamon support for appindicators appears to be a bit rough: I also couldn't get the Signal tray icon to show up, for example.

I can confirm that changing that setting in cinnamon has fixed the issue, though this icon behaves a bit differently.

[p3x-robot]

"System Settings" -> "General" -> "Enable support for indicators"

This fixed it.

[vladimiry]

In https://bugs.archlinux.org/task/65483 they say that even if you enable the Enable support for indicators some issues still remain. But if you experience no issues of course let's close this issue then.

[clefebvre]

"System Settings" -> "General" -> "Enable support for indicators"

This fixed it.

That's not a fix, that's a workaround, and not a good one imo.

libappindicator falls back to xembed (gtk.statusicon) when no appindicator applet is found (i.e. when that setting is OFF).. and in Mint it is patched to fallback to xappstatusicon which supports HiDPI and symbolic icons and which itself falls back to xembed as a last resort.

If you want something that works everywhere you need to either support xembed, or support something which falls back to it.

[clefebvre]

Afaik we've currently no way of supporting StatusNotifier without enabling libappindicator support in Cinnamon and doing so seriously regresses the user experience with many apps.

[clefebvre]

@p3x-robot what app do you test this with? I noticed keybase was mentioned in the Arch bug report, it seems to be a CLI app though.

Just to summarize the current state of things in Cinnamon in regards to tray technology:

• Xembed is always supported.
• XappStatusIcon is supported by default.
• LibAppIndicator is supported if "Enable support for indicators" is enabled.
• StatusNotifier (apps using this straight away without using LibAppIndicator) is supported if "Enable support for indicators" is enabled.

In terms of API now:

• gtkstatusicon uses xembed directly. That works everywhere in Linux except in Plasma 5 afaik and it has limitations (no HiDPI support, no Wayland support etc..).
• xappstatusicon uses its own protocol and falls back to xembed if none of its applets are present. That works in Cinnamon, MATE and Xfce.
• libappindicator is a wrapper around StatusNotifier and falls back to xembed it none of its applets are present. That works in all DEs afaik, but because libappindicator is only a client side API, there are a lot of variations when it comes to applets.. some of them work well, some of them don't. In Mint, libappindicator doesn't fall back straight to xembed, it falls back to xappstatusicon first.
• libayatana is a fork of libappindicator, it might worth including them in the discussion as well.

Xembed should be a last resort, it's the worst solution really, but because it works everywhere we should definitely make sure to always fall back to it. I'm not sure how this is is implemented in electron... but if you use StatusNotifier without using libappindicator, you might be missing that important fallback mechanism.

[clefebvre]

I asked @mtwebster to shine in on this, he's more experienced than me when it comes to xappstatusicon and the fall back mechanisms in it and in libappindicator.

[p3x-robot]

• gtkstatusicon uses xembed directly. That works everywhere in Linux except in Plasma 5 afaik and it has limitations (no HiDPI support, no Wayland support etc..).
• xappstatusicon uses its own protocol and falls back to xembed if none of its applets are present. That works in Cinnamon, MATE and Xfce.
• libappindicator is a wrapper around StatusNotifier and falls back to xembed it none of its applets are present. That works in all DEs afaik, but because libappindicator is only a client side API, there are a lot of variations when it comes to applets

I use the tray for p3x-onenote: https://github.com/patrikx3/onenote

You can try with latest for example AppImage, you have to Enable support for indicators, otherwise it is not working.

[clefebvre]

Thanks @p3x-robot, I can reproduce it with https://github.com/patrikx3/onenote/releases/download/v2020.4.131/P3X-OneNote-2020.4.131.AppImage.

• System Settings -> General -> Enable support for Indicator -> ON
• Alt+F2+r
• Launch OneNote, no need to sign in.
• Settings -> Close to Tray
• tray icon appears

Test again with support for indicators disabled, no icon appears in the tray.

It looks like the app uses the StatusNotifier dbus bus (and so it's picked up by our applet when indicator support is enabled) but it doesn't seem to use libappindicator, otherwise that would make it fallback to xembed when our support for indicators is disabled.

[mtwebster]

@p3x-robot hi I've been working on support for this (linuxmint/xapp#89) and using that onenote app for testing.

One thing I noticed, in comparison to the other programs I'm testing with (all of which use libappindicator) that the app only attempts once, at startup, to establish a status icon. If, for instance, I kill my watcher program, and restart it, the onenote icon never returns (until I kill and restart it).

It's not a huge deal, and this could very well be a bug on my end - I'm just trying to make sure our StatusIcon support will behave as expected (there's is not a lot of consistency with this around the different implementations), and thought I'd mention this behavior. Most users won't be constantly restarting their desktop and would never notice this.

[mtwebster]

@p3x-robot nevermind, I think I just realized my issue

edit - I was wrong again - but I think this is such an unlikely occurrence I'm not going to worry about this. Under normal circumstances the watcher never exits, except when you log out.