ransome1 / sleek

todo.txt manager for Linux, Windows and MacOS, free and open-source (FOSS)
https://github.com/ransome1/sleek/wiki
MIT License
1.37k stars 105 forks source link

[KDE] Systray icon malfunctions #548

Closed callegar closed 9 months ago

callegar commented 11 months ago

Bug Report

App Version:

Platform: [Windows / macOS / Linux]

Linux, wayland, kde

Installation Method: [App Store / Direct Download / Other]

Bug Description:

The systray icon malfunctions. Most of the time clicking on it you do not get any action/menu. I reealize this may not be very important as a new version of sleek in on the way. Still, should a further point release be considered for the 1.3 series this might be worth fixing.

Steps to Reproduce:

  1. Start sleek
  2. click on the systray icon

Expected Behavior:

Clicking on the icon you get a menu from which you can open the application window and control some features of the application.

Actual Behavior:

Clicking on the icon does nothing.

Additional Information:

Maybe the matter is with the adopted libappindicator and switching to libayatana-appindicator can help.

Screenshots: [If applicable, include screenshots that demonstrate the bug.]

System Information:

Reproducibility:

Impact:

Workaround: [If you found any temporary workaround for the bug, please mention it here.]

ransome1 commented 11 months ago

I prepared the Flathub build process for the upcoming 2.0.

Can I ask you to take a look at the Flatpak and give me a feedback, if it works on your side and, of course, if the tray issue is solved?

You can install the test build with this: flatpak install https://dl.flathub.org/build-repo/59575/com.github.ransome1.sleek.flatpakref

In case stuff is not working, please run it with: flatpak run com.github.ransome1.sleek and share the warnings and errors, which might pop up there.

callegar commented 11 months ago

Hi, thanks for the experimental flatpak build. Some quick feedback about it:

  1. at start you get the warning [2:1028/112149.151686:ERROR:bus.cc(399)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory, weird because run/dbus/system_bus_socket is there. Is sleek looking for it in the flatpak chroot?
  2. there is no automatic migration of the data from 1.3.1 (with particular respect to the location of the todo file).
  3. the systray icon is there, but has issues:
    • it is quite blurry
    • its working in opening a menu as you click on it is quite erratic (sometimes it works, most of the time it does not). So in many cases, once you have minimized sleek to the systray, it is impossible or extra hard to bring it back.

As an additional, general remarks on 2.0

Thanks again for the intense work on the rewrite!

ransome1 commented 11 months ago

at start you get the warning [2:1028/112149.151686:ERROR:bus.cc(399)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory, weird because run/dbus/system_bus_socket is there. Is sleek looking for it in the flatpak chroot?

I honestly don't know. It's mostly related to some missing configuration in the Flatpak manifest. I'm getting those errors here as well but I'm not experiencing any issues in sleek related to this.

there is no automatic migration of the data from 1.3.1 (with particular respect to the location of the todo file).

There won't be a migration function, since it is 10 seconds of work on the user side and hours on the developers ;)

the systray icon is there, but has issues: That seems something Plasma specific. I set up a VM with Manjaro and can reproduce the issue with the blurry icon. Not sure yet why this happens, on Gnome and XFCE (as well as Windows and macOS) it is sharp.

its working in opening a menu as you click on it is quite erratic (sometimes it works, most of the time it does not). So in many cases, once you have minimized sleek to the systray, it is impossible or extra hard to bring it back.

I'm not sure what you mean with that. The only thing implemented is the right click, which opens a menu. What is the expected behavior on a tray icon on Linux if you left click it?

callegar commented 11 months ago

The only thing implemented is the right click, which opens a menu

That's the erratic thing. When you right click, often the menu does not open.

ransome1 commented 11 months ago

@callegar could you please try to download the AppImage of the latest dev preview and check if you experience the same with it? I can reproduce it with Flatpak, but not when I use the AppImage or simply build sleek from source code. Curious if this is the same on your side.

callegar commented 10 months ago

Probably related to (or same of) issue 580 - Tray icon fails to load

ransome1 commented 10 months ago

On Windows and macOS the Electron tray API provides us with events for left and a right click. On Linux there is only one click event we can use. So we need to choose wisely what the most likely expected behavior for a click on the tray icon in Linux is. In another thread a user is pointing out he is expecting the app to open on click.

In this pre-release I implemented:

macOS and Windows

@callegar what's your take on this?

andrei-a-papou commented 10 months ago

@ransome1 I played with the tray icon feature on Linux and would definitely agree with https://github.com/ransome1/sleek/issues/580 and your comment above that left-clicking should show sleek. In fact it should toggle it: if sleek is visible, hide it. If sleek is minimized to tray, show it and focus the window. Ideally, the menu item label should change accordingly.

Also, right now the app gets hidden in the tray only when I close the window. I think it should do that also when minimizing the window (provided the Minimize to tray option is enabled of course). I could convert this to a separate issue if that works better and can help testing the tray feature under Linux.

callegar commented 10 months ago

On Linux this is not OK, IMHO. If you have the minimize to tray function on, you cannot terminate the application in any way (other than from a shell with the kill command). You need the context menu on the mouse button for that.

andrei-a-papou commented 10 months ago

@callegar But you can always right-click the tray icon and click "Quit", no? :)

image

callegar commented 10 months ago

Right click appears to have no function anymore in Linux (see above).

ransome1 commented 10 months ago

On Linux this is not OK, IMHO. If you have the minimize to tray function on, you cannot terminate the application in any way (other than from a shell with the kill command). You need the context menu on the mouse button for that.

You can use the window menu to fully quit the application.

andrei-a-papou commented 10 months ago

@callegar Oh, right. Missed that. I would still say minimizing to tray should minimize to tray, not leave the window visible in the taskbar. Otherwise the option sounds kind of confusing, IMO. Perhaps if the option was called "Minimize to tray instead of closing", @ransome1 what do you think?

As far as quitting the app goes, how about opening it and pressing Ctrl-Q or quitting it from the menubar?

Personally, leaving the app visible in the taskbar on minimize would be OK with me -- but IMO the setting label needs to be rephrased in this case.

callegar commented 10 months ago

Compared to sleek 2.02 there is no more menubar, so I do not have a sleek menu with the quit entry. I can press "close" from the window bar or the task manager, but when "minimize to tray" is active those leave the application running in the system tray.

callegar commented 10 months ago

Incidentally, with no menubar, in 2.0.3RC3 I do not know how to archive completed tasks either.

ransome1 commented 10 months ago

If you press Alt, the menu appears on Linux and Windows. The shortcut for archiving is Ctrl + Alt + A

ransome1 commented 10 months ago

@callegar Oh, right. Missed that. I would still say minimizing to tray should minimize to tray, not leave the window visible in the taskbar. Otherwise the option sounds kind of confusing, IMO. Perhaps if the option was called "Minimize to tray instead of closing", @ransome1 what do you think?

I'm not sure if I understand what you're referring to here.

andrei-a-papou commented 10 months ago

@ransome1 I meant this option's label:

image

Right now it says "Minimize to tray", yet when I minimize the window, it doesn't get minimized to tray. It's still visible in the taskbar. The app hides to tray only when I close the window.

To me, the behavior is unexpected given the option's current name/label. IMO, either the option should say something like "Minimize to tray instead of closing", or the app should be hidden to tray when minimizing the window. Then it would be consistent UX.

ransome1 commented 10 months ago

@andrei-a-papou @callegar can Minimize to tray instead of closing lead to some minor confusion? It does somehow implicate, that closing the app using keyboard shortcut or window menu, does minimize it to tray. Which is not the actual behavior.

We could be more generic and name it Show sleek in tray. This does not try to describe the behavior. Any thoughts?

andrei-a-papou commented 10 months ago

It does somehow implicate, that closing the app using keyboard shortcut or window menu, does minimize it to tray.

@ransome1 That's exactly the behavior I get :) And that's why I proposed the wording I did :)

This is under Linux, Xfce.

With the option enabled, closing the window hides sleek in tray (but IMO confusingly leaves it visible in taskbar). The only way to actually quit the app is via the in-app menu or by pressing Ctrl+Q (or sending a signal via CLI, but that's a different story).

Is this not the designed behavior? If so, what was the idea?

andrei-a-papou commented 10 months ago

@ransome1 IMO, Show sleek in tray is OK but I would reword it to simply Use tray icon. Or Show tray icon (the wording that Joplin uses).

Still, my slight beef with it is exactly the fact that this wording would not describe the actual behavior :) But I agree it would be a step forward and cause less confusion. So personally I'd be fine with this trade-off.

ransome1 commented 10 months ago

When tray option is enabled, the idea is that clicking on the X in the top window bar does not quit the app, but instead minimizes it.

It should (and does on Windows macOS) not appear in the taskbar neither (on macOS it's the dock).

Using Ctrl or CMD + Q is suppose to quit the app.

As does using the Quit option in the window menu.

Both options must quit the application, it should not continue running in the background and should be visible only in tray.

But I just started up my Linux VM (Ubuntu with Gnome) and discovered, that clicking on the tray icon doesn't do anything any more :/ This seems to be connected to a change from a couple of days earlier. Unfortunetly some Linux desktops (Gnome in my case) don't trigger the corresponding Electron event in the app.

It looks like the only reliably working way cross platform is to offer one single click on tray. Which opens the context menu.

andrei-a-papou commented 10 months ago

It should (and does on Windows macOS) not appear in the taskbar neither (on macOS it's the dock).

This doesn't happen under Xfce. Then again I wouldn't expect it if the config setting simply said Show tray icon instead of mentioning minimizing.

It looks like the only reliably working way cross platform is to offer one single click on tray. Which opens the context menu.

Then perhaps sleek could do what Joplin does: both left- and right-click on the tray icon open a context menu with two items: Open sleek and Quit. That would help with quitting too. What do you think?

image

ransome1 commented 10 months ago

That is also sleek old behavior and I think we should regress to it. I think some users will want to have it work differently, but as long as the Electron APIs don't support a reliable behavior across platform and across desktop environment, without workarounds, we should stick to what works.

andrei-a-papou commented 10 months ago

Good point. Given Electron's limitations, I'm fine with tray icon opening a context menu, as was the case with sleek 2.0.2.

However, in sleek 2.0.2 the left click on the tray icon simply does nothing, which gives an impression of something being broken :(

Could you maybe take a look at how Joplin does it? With Joplin, both left- and right-click show the context menu, which offers a better UX, IMO

andrei-a-papou commented 10 months ago

@ransome1 I noticed another UX annoyance with the tray icon:

  1. have multiple TODO files open in sleek
  2. switch between them via Ctrl-1/Ctrl-2/etc or by clicking on tabs
  3. every time sleek focuses a new file tab, the tray icon is quickly removed and then re-added to the notification area/systray, which causes flickering and redrawing.

This happens in v2.0.2 as well as 2.0.3 RCs.

ransome1 commented 10 months ago

@andrei-a-papou the flickering should be fixed in https://github.com/ransome1/sleek/releases/tag/v2.0.3-rc.5. However, when adding or removing a file the flickering will continue to occur, because the tray needs to be re-created with the updated file list. On my Mac I haven't really been able to see the flickering, I assume it might be occurring on Linux or maybe on older hardware.

Also sleek's old behavior of how the tray works has been restored. Both clicks will open the context menu.

The option label in sleeks settings has also been updated.

andrei-a-papou commented 10 months ago

@ransome1

  1. tray flickering is gone (also, I can't reproduce the issue in https://github.com/ransome1/sleek/issues/599 anymore)
  2. the tray icon does flicker briefly when a new TODO file is added, but that is no big deal; if there was an option to disable those menu entries in the tray icon menu, I would hide them, but again -- no big deal at all, just an idea
  3. option label is fine now, thank you
  4. right click on tray icon works fine, but left click doesn't show the menu on Xfce :( Neither does it work in 2.0.2, by the way, just tested. Is it possible for you to run Xubuntu (not GNOME) to check it out? Or what can I do to help debug this on my end?
ransome1 commented 9 months ago

right click on tray icon works fine, but left click doesn't show the menu on Xfce :( Neither does it work in 2.0.2, by the way, just tested. Is it possible for you to run Xubuntu (not GNOME) to check it out? Or what can I do to help debug this on my end?

Some time ago I still had access to my Arch Linux machine, on which XFCE was installed and I recall this behavior. Even with all the workarounds I could not get the left click to call sleeks context menu. It always showed me some window configuration menu. Other apps (non Electron app though) were having their own context menu and so I suspected this to be a limitation of Electron. But I didn't dig into it. On Gnome the behavior seems to be, that only the right click triggers the context menu and the left click doesn't do anything. On KDE I hope @callegar can give us feedback for the 2.0.3 release. On Windows and macOS both mouse clicks work. It's a bit nebulous to be honest.

I'm not sure if there is an Electron-way yet to implement the tray behavior to be fully compatible with every Linux desktop environment in sleek. And maybe this is something which needs to be fixed in Electron. The way it is implemented right now, is the text book way by using the setContextMenu method. Many workarounds I have had undertaken solved the issue on one desktop environment and crashed it on three other ;)

andrei-a-papou commented 9 months ago

@ransome1 I realize Electron is probably finicky in terms of tray icon, but would it be possible for you to take a look at how Joplin does it? See https://github.com/laurent22/joplin/blob/de67ec46846b608584ce2402da9c4307e60dfdda/packages/app-desktop/ElectronAppWrapper.ts#L366C44-L366C44

I just tested the latest Joplin AppImage and it works perfectly: left click focuses the Joplin window, right click pops up context menu. (A previous version that I just upgraded from would pop up the context menu on both the left and right click, but the latest version does the "right thing".)

Can you run Joplin under GNOME and see if left and right click work properly? If so, perhaps sleek could do what Joplin does, at least conditionally for Linux and leave the existing logic for Windows and macOS as is.

On Gnome the behavior seems to be, that only the right click triggers the context menu and the left click doesn't do anything.

Yes, same on Xfce with sleek 2.0.3. Left click feels broken.

andrei-a-papou commented 9 months ago

@ransome1 Thank you for looking into it, both left and right click work, finally! Does it work under GNOME also?

ransome1 commented 9 months ago

@andrei-a-papou unfortunately it does not :/ However I installed Joplin, where it actually works. So there is still something missing in my implementation. Let's see what I can find.

andrei-a-papou commented 9 months ago

@ransome1 Just FYI, latest Joplin and latest sleek do not use the same Electron version, Joplin's newer (if I remember correctly). Just an idea.

ransome1 commented 9 months ago

I just double checked Gnome and realized, that I tested the wrong version (2.0.3). The 2.0.4-rc.1 does trigger the context menu on left and right click on Gnome. If this happens on Xfce and Windows and macOS as well, we should now have a consistent behavior across all platforms.

andrei-a-papou commented 9 months ago

If this happens on Xfce and Windows and macOS as well, we should now have a consistent behavior across all platforms. That is awesome!

Would it be possible to enhance left-click behavior so it toggles sleek rather than only shows it? That's what many apps do with their tray icons (e. g. Telegram, KeePassXC, etc) and I think many users expect it.

So the behavior I'm proposing is this:

  1. if window is open but not focused, left-click focuses it -- already works
  2. if window is open and focused, left-click hides it to tray (provided the appropriate config setting is on)
  3. if window is hidden in tray, left-click opens and focuses it -- already works

I think that would enhance the UX as sometimes a user just needs to look at the todos without changing anything -- and he will be able to do it with a couple mouse clicks, without having to move the mouse to the window close button to hide sleek.

ransome1 commented 9 months ago

Could you please create a dedicated enhancement issue for any further adjustments? I would like to close this issue, because we're drifting away form the initial bug report.

andrei-a-papou commented 9 months ago

Will do!