Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tray Icon problems on Linux #1153

Closed
hacdias opened this issue Sep 27, 2019 · 27 comments
Closed

Tray Icon problems on Linux #1153

hacdias opened this issue Sep 27, 2019 · 27 comments
Labels
area/linux Linux kind/bug A bug in existing code (including security flaws) kind/maintenance Work required to avoid breaking changes or harm to project's status quo need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up status/in-progress In progress

Comments

@hacdias
Copy link
Member

hacdias commented Sep 27, 2019

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.

@hacdias hacdias added P2 Medium: Good to have, but can wait until someone steps up area/linux Linux labels Sep 27, 2019
@NatoBoram
Copy link

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
Copy link
Member

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
Copy link

NatoBoram commented Sep 30, 2019

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
Copy link
Member Author

hacdias commented Oct 7, 2019

...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
Copy link

Lazerbeak12345 commented Nov 15, 2019

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
Copy link
Member

lidel commented Mar 9, 2020

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:

@vladimiry
Copy link

Electron 8 switched to it,

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

@dotenorio
Copy link

See my solution:

zulip/zulip-desktop#910 (comment)

@lidel
Copy link
Member

lidel commented Apr 17, 2020

@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).

This was referenced Apr 17, 2020
@lidel
Copy link
Member

lidel commented Apr 17, 2020

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
Copy link
Member

lidel commented Apr 19, 2020

@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 🙃):

2020-04-20--01-24-34

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
Copy link

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
Copy link
Member

lidel commented May 26, 2020

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 lidel reopened this May 26, 2020
@lidel lidel added the kind/maintenance Work required to avoid breaking changes or harm to project's status quo label May 26, 2020
@lidel lidel added need/analysis Needs further analysis before proceeding status/in-progress In progress labels May 26, 2020
@lidel lidel changed the title No Tray Icon on Linux Tray Icon problems on Linux Jul 31, 2020
@lidel
Copy link
Member

lidel commented Jul 31, 2020

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 lidel added kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up and removed P2 Medium: Good to have, but can wait until someone steps up labels Jul 31, 2020
@mskiptr

This comment has been minimized.

@lidel
Copy link
Member

lidel commented Sep 14, 2020

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

@lidel
Copy link
Member

lidel commented Oct 5, 2020

@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
Copy link
Contributor

@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
Copy link
Member

lidel commented Oct 6, 2020

@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
Copy link
Member

lidel commented Oct 7, 2020

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
Copy link

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
Copy link

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
Copy link

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
Copy link
Member

lidel commented Sep 28, 2021

@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
Copy link

teohhanhui commented Sep 29, 2021

Discord, for example.

Screenshot from 2021-09-30 00-26-20

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
Copy link

NatoBoram commented Sep 29, 2021

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/linux Linux kind/bug A bug in existing code (including security flaws) kind/maintenance Work required to avoid breaking changes or harm to project's status quo need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up status/in-progress In progress
Projects
None yet
Development

No branches or pull requests

10 participants