Tray Icon problems on Linux

[hacdias]

So, there are quite a few issues with people complaining they can't access the UI of IPFS Desktop on Linux. All of them are caused by the same reason: tray icons are being deprecated from many desktop environments and Electron has not yet worked out on a solution, nor it seems to be happening soon.This affects all kinds of packages.

One possible way for us to circumvent this for now is to open the main Web UI window on Linux on startup. However, that will still leave the options of exiting desktop and other options provided by the menu behind.

I'm opening this in hope to gather feedback on how to create an workaround around this.

Please note that Linux support is experimental nonetheless.

[NatoBoram]

Hm, not a fan of this solution.

Tray icons are an important feature. The desktops missing them are just deficient, intentionally or not, and regardless of their design philosophy.

A better solution would be to open a window when clicking on the application's launcher. That way, it now gains a behavior that's intuitive (clicking on a launcher generally launches the app) and it fixes the tray icon problem rather than creating a missing tray icon problem for other Linux users.

[olizilla]

As a first step, we can have desktop open the webui window on launch as suggested. I'm not clear on how we can show the user that the app is still running if they close the window... what happens on others apps that are long running on desktops that dont have task tray icons?

[NatoBoram]

what happens on others apps that are long running on desktops that dont have task tray icons?

I don't know any long-running apps without tray icons except for command-line apps, but those don't even have desktop icons in the first place. For long-running apps with a tray icon on systems without a system tray, however, I've noticed a pattern.

• Skype launches its UI when clicking its icon even if it's already launched in background.
• Discord launches its UI when clicking its icon even if it's already launched in background.
• Steam launches its UI when clicking its icon even if it's already launched in background.
• Chrome launches its UI when clicking its icon even if it's already launched in background.
• qBitTorrent launches its UI when clicking its icon even if it's already launched in background.
• Teams launches its UI when clicking its icon even if it's already launched in background.
• MSI Afterburner launches its UI when clicking its icon even if it's already launched in background.
• GeForce Experience launches its UI when clicking its icon even if it's already launched in background.
• IPFS-Desktop doesn't react.

None of them closes on close. They minimize on minimize and go to system tray on close.

One problem that may arise is that options in the tray app will be hidden. This can be fixed by having them accessible from inside the app as well.

[hacdias]

...we can have desktop open the webui window on launch as suggested.

I absolutely agree, but we should do that only on Linux perhaps. And even there some issues might arise... What about those users who have IPFS Desktop setup to start up automatically when they turn on the computer? I doubt anyone wants a window to be open in those cases.

I can investigate to see if there's any way to know if the app is being launched by a startup mechanism or not.

[Lazerbeak12345]

I like your idea about doing that on only Linux @hacdias, but perhaps we should be even more specific. On the default KDE layout, for example, it has a system tray, and it works perfectly, however, on Gnome, there seems to be no tray whatsoever.

• edit: by "perfectly" I mean just like it would on windows.

[lidel]

Note to self: Tray support on modern linux DE is severely broken.
Pure saddness: electron/electron#21445

Seems that old Tray support was replaced with StatusNotifier spec, and Electron 8 switched to it, but not every DE supports it out of the box:

• KDE: supported out-from-the-box.

• Xfce: supported (xfce4-statusnotifier-plugin needs to be installed and then respective widget added to the panel). There is also gitlab.com/vala-panel-project/xfce4-sntray-plugin working plugin, alternative to xfce4-statusnotifier-plugin.

• Gnome Shell: supported with the help of preinstalled gnome-shell-extension-appindicator extension but the tray/menu clicks might act flaky (respective issue placed).

• Cinnamon / Mint: "System Settings" -> "General" -> "Enable support for indicators" flag needs to be enabled. Some issues still possible, see linuxmint/cinnamon#9176. should be fixed by linuxmint/cinnamon@eb7f223

• polybar: not supported (respective issue placed).

[vladimiry]

Electron 8 switched to it,

@chromium did and Electron v8 took it as a given thing.

[dotenorio]

See my solution:

zulip/zulip-desktop#910 (comment)

[lidel]

@dotenorio I am afraid the code you linked is a fix for other issue (electron/electron#22443).

I don't believe it solves the mess of Electron 8 switching to StatusNotifier and breaking Tray icon in various Linux setups as noted in electron/electron#21445 (comment).

[lidel]

For testing purposes, I was able to get tray icon back on i3bar
with https://git.sr.ht/~steef/snixembed (a StatusNotifier→XEmbed proxy)
Unfortunately it is not something we can bundle with ipfs-desktop.

[lidel]

@hacdias the screenshot of Lungo app you posted in the other issue inspired me to come up with a potential workaround for Linux for next 10 years (until everyone switch to StatusNotifier 🙃):

Idea:
What if we add "Show WebUI at Launch" feature to ipfs-desktop and enable it by default on Linux?

Rationale:

• if user does not have the tray icon in Linux DE
  • clicking ipfs icon is "Applications" would start node and show webui
  • closing webui would keep daemon running
  • clicking "IPFS Desktop" in "Applications" again would show webui
  • downside: no controls for stopping node, but its better than clicking on icon and nothing happening
• if user has the tray icon in their Linux DE and does not want webui to show on startup, they can disable it with one click

[vladimiry]

What if we add "Show WebUI at Launch" feature to ipfs-desktop and enable it by default on Linux?

I ended up with this scenario for Linux users of ElectronMail (ref1, ref2).

[lidel]

Thanks for heads up in the original issue @vladimiry!

To whom it may concern. It turned out Electron is getting rid of DBus related tray icon implementation rolled out with chromium update in Electron v8 in favor of previously used / GTK/appindicator approach, see electron/electron#23674.

Let's reopen this and track progress in electron/electron#23674 – if Electron indeed restores old tray support, that would be great news for our Linux users.

[lidel]

electron/electron#23674 got merged and backported to 8.x: electron/electron#23674 (comment)

It seems to be the lesser evil that is here to stay for a few more years.

@rafaelramalho19 I believe upgrading to electron v8.4.1 should include the above "fix". Sooner we switch, the sooner we identify any UX regressions caused by it on various Linuxes.

[lidel]

Heads up: we are planning to switch to Electron 9 in the next release, and it will include change described in #1153 (comment)

[lidel]

@bertrandfalguiere thank you for testing v0.13.0 with Electron 9.x across different distros in #1661 ❤️
Do you know how does the tray icon behave now? Which desktop environment were you using for tests?
Is there anything we should improve in https://github.com/ipfs-shipyard/ipfs-desktop/#no-tray-icon-on-linux ?

[bertrandfalguiere]

@lidel The tray icon behave nominally now on my system with v0.13.0 :).
I tested with Ubuntu 20.04. I don't know which app indicator I'm using. I think the default one, which should be Gnome Shell?
I haven't tested on other distros (and probably won't).

[lidel]

@bertrandfalguiere that is enough, thank you! I was mostly worried about Ubuntu, as historically they used custom stuff and hid tray indicators. Seems that Electron 9.x correctly supports whatever Ubuntu uses these days, so all good 👍

This issue can be closed when v0.13 ships (#1661)

[lidel]

I believe this should be fixed in v0.13, but please reopen if you experience any tray problems (include info about your distro and DE/WM/tray setup)

[teohhanhui]

There really should be a way to use IPFS Desktop without any tray icon.

For example, GNOME by default does not include any appindicator support, and as a user that's not something I'd change.

[Lazerbeak12345]

I'd just like to add, that while I do very much agree with @teohhanhui , many other native linux apps ported from windows (such as zoom) make the same tray icon assumptions. I feel that Gnome shouldn't have removed that appindicator support, but now that they have, I wouldn't imagine that all users would want to go through the process of setting it up. (On the other hand, most other DE's do include appindicator support)

[teohhanhui]

GNOME did it for good reason: https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/

Anyway, the reality is that it's highly unlikely for appindicator or similar to be supported by default: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1014

So app developers should provide a way to use the app without tray icon. It's not that hard. Many other apps have done it.

[lidel]

@teohhanhui do you have examples of some apps that do it "correctly"? Would be really useful to study their behavior and implement something similar.

[teohhanhui]

Discord, for example.

Use of the tray icon should be entirely optional. Relevant items from the tray menu can be duplicated in an in-app menu.

But even Steam's behaviour (close never exits; the user has to explicitly select "Exit" from the in-app menu), while not ideal, is still better than what IPFS Desktop is doing now.

[NatoBoram]

Do you have examples of some apps that do it "correctly"? Would be really useful to study their behavior and implement something similar.

Just to make sure, @lidel, are you asking for this list again?

what happens on others apps that are long running on desktops that dont have task tray icons?

I don't know any long-running apps without tray icons except for command-line apps, but those don't even have desktop icons in the first place. For long-running apps with a tray icon on systems without a system tray, however, I've noticed a pattern.

• Skype launches its UI when clicking its icon even if it's already launched in background.
• Discord launches its UI when clicking its icon even if it's already launched in background.
• Steam launches its UI when clicking its icon even if it's already launched in background.
• Chrome launches its UI when clicking its icon even if it's already launched in background.
• qBitTorrent launches its UI when clicking its icon even if it's already launched in background.
• Teams launches its UI when clicking its icon even if it's already launched in background.
• MSI Afterburner launches its UI when clicking its icon even if it's already launched in background.
• GeForce Experience launches its UI when clicking its icon even if it's already launched in background.
• ShareX launches its UI when clicking its icon even if it's already launched in background.
• IPFS-Desktop doesn't react.

None of them closes on close. They minimize on minimize and go to system tray on close.

One problem that may arise is that options in the tray app will be hidden. This can be fixed by having them accessible from inside the app as well.

[vladimiry]

launches its UI when clicking its icon even if it's already launched in background.

For example in https://github.com/vladimiry/ElectronMail when it's already started and you launch its binary/shortcut again it will open/activate the window of already executed app instance. Some users bind the binary execution to a hotkey and so they use the hotkey to unhide the app from the tray (from the hidden state if there is no tray).

None of them closes on close. They minimize on minimize and go to system tray on close.

Pretty regular behavior on Windows systems. It's good though if there is an option to make the window close action close the app.

This can be fixed by having them accessible from inside the app as well.

This is how it's done in ElectronMail.