Left-click doesn't open tray menu on Gnome

[sandrotosi]

Describe the bug
clicking on the notification bar icon doesnt open the application

To Reproduce
Steps to reproduce the behavior:

1. have vorta running, so an icon in the notification area is displayed
2. Click on the notification icon, nothing happens

expectation is to get vorta to open, instead i need to right click and select "Vorta for Borg Backup"

Environment (please complete the following information):

• OS: Debian unstable
• Vorta version: 0.7.5
• Installed from: debian package

[m3nu]

For Linux this is different for each desktop. AFAIK KDE already has the behavior you describe. If you use Gnome and want to play with the settings:

https://github.com/borgbase/vorta/blob/master/src/vorta/tray_menu.py#L26

[sandrotosi]

Indeed i'm running on Gnome, which was not included in that filter. I've managed to get it to work changing line 26 into:

if os.environ.get('XDG_CURRENT_DESKTOP', '').startswith(('KDE', 'GNOME')):

As it appears XDG_CURRENT_DESKTOP can be a string containing multiple items separated by a colon (https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1554878) and on my machine it is indeed:

$ echo $XDG_CURRENT_DESKTOP
GNOME-Flashback:GNOME

This is an example of how XDG is detecting DEs in their own scripts. If you still want to filter per DE, this may be a good start

I'm also wondering what is the reason for the filter in the first place: are there some DEs that dont support self.app.toggle_main_window_visibility() ?

[m3nu]

You can use the Blame feature of that file to see where and why the filter for KDE was added. IIRC it was to get the icon behavior in line with the conventions of that desktop.

We can definitely make changes here, but they should be in line with user expectations. E.g. on macOS, all icons open a menu. If e.g. on Gnome they usually open the app’s man window, we can adjust the behavior.

Even though the actual code change is trivial, any change should be well-planned, since it touches the UX directly.

[m3nu]

Just tried in Gnome and it makes more sense to open the window on left-click instead of doing nothing.

If there are no objects, to the PR, I'm OK to add the new behavior you suggested.

[m3nu]

Looks like this is more complicated. As Julian correctly points out, the normal behavior is to open the menu when clicking the icon. No matter how it's clicked.

For KDE, an exception was added due to their guidelines.

The behavior that you are observing seems to be a bug in Qt, where the context menu doesn't open on left-click, even though the event is triggered correctly.

I tried using a different way to open the menu (self.contextMenu().popup(QCursor.pos())), but then the positioning is slightly off, so can't use that either.

[sandrotosi]

tbh i dont find that a valid argument: i would find it confusing to get presented the menu when left clicking, since the menu is usually presented when right clicking

[sten0]

Hi @m3nu! This isn't a GNOME-specific bug, and it appears to be Vorta-specific rather than a bug in Qt. The steps @sandrotosi and I took to investigate this can be found at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985252 and I hope consulting the PyQt application we used to determine this may be useful in developing a solution :-)

Special-casing KDE doesn't make sense to me, because system tray support is a FreeDesktop/XDG spec, and other desktops such as XFCE or XDG window managers such as Openbox (in combination with an XDG-compliant dock like tint2) are also affected. https://www.freedesktop.org/wiki/Specifications/systemtray-spec/.

If a check needs to be added to differentiate between Linux and MacOS, why not check if XDG_CURRENT_DESKTOP is None, skip the branch if it's None, and otherwise do the expected XDG-compliant thing, which is right click to open a context menu, and left click to restore the application. The GTK Transmission try applet, the Transmission-qt tray applet, and Clementine's tray applet are other examples of the expected behaviour.

I do agree with @Hofer-Julian, and that ideal GNOME3 GNOME Shell support would have a GNOME extension and not use the tray applet, but that's currently outside of Vorta's scope (as are KDE-native Plasma widgets); also, GNOME Shell users who use tray applets install an extension to support them, and many users believe that the GNOME project is insane to not provide default for them by default. Sandro is reporting an issue on GNOME-Flashback which continues to support a traditional XDG-compliant tray without 3rd party extensions.

That said, IIRC there are applications that don't show the main when when the tray applet is left clicked (IIRC maybe Amanda and/or Bacula?), but in this case the semantics are that the tray applet exists solely to monitor a background daemon--which doesn't accurately describe Vorta's design at this point in time--thus I recommend implementing standard XDG-compliant tray behaviour for XDG Desktops, with no further special casing.

[m3nu]

Thanks for weighing in, everyone. No problem to adjust the behavior, if there really is a standard. Also added a special case for macOS, which doesn't have left/right click. PR #945

Tested on Fedora 33/Gnome, Debian 11/KDE and macOS

I should monitor the Debian bugtracker in the future to stay up-to-date. 😄

• Relevant part of the sample app you mentioned: https://github.com/jmechnich/weather-applet/blob/736cfd4212ba37d2a06b95f388dc7dca672955a7/weatherapplet/weather.py#L183
• Qt activation reasons: https://doc.qt.io/qt-5/qsystemtrayicon.html#ActivationReason-enum

[sten0]

Hi Manu, Manu ***@***.***> writes:

Thanks for weighing in, everyone. No problem to adjust the behavior, if there really is a standard.

Thank you :-) And yes, indeed, the problem with standards is usually https://xkcd.com/927. XDG and Freedesktop are really a standard, but GNOME Shell is the odd duck that wants to "innovate" outside of the standards--something that remains controversial to this day.

Also added a special case for macOS, which doesn't have left/right click. PR #945

OT, but if you're interested in computer history, see this gorgeous model with the first mouse--a three button mouse: https://en.wikipedia.org/wiki/Xerox_Alto X11/Xorg support that original spec, and highlighting text with the left mouse button, then clicking the mouse wheel somewhere else will paste the selected text to the point of the middle (3rd) mouse button click. No idea if Wayland supports it, but it's a power user killer feature but https://www.cnbc.com/2018/05/21/why-your-computer-has-a-mouse-according-to-steve-jobs.html which GNOME's philosophy is similar to, probably originally due to Bud Tribble (of Apple), Eazel (https://en.wikipedia.org/wiki/Eazel) and the enthusiasm of the second generation Linux Desktop (as seen in the movie Antitrust), whose objective was to make computing even easier than a Mac, while being more powerful. To be fair, OS X solved a lot of the limitations of Classic MacOS :-)

Tested on Fedora 33/Gnome, Debian 11/KDE and macOS

I wish all projects were as dedicated to testing! This inspires me to work harder, and do better testing :-)

I should monitor the Debian bugtracker in the future to stay up-to-date. 😄

Haha! Sorry, this is my fault, since one of my responsibilities is to forward to upstream bugs that affect upstream.

- Relevant part of the sample app you mentioned: https://github.com/jmechnich/weather-applet/blob/736cfd4212ba37d2a06b95f388dc7dca672955a7/weatherapplet/weather.py#L183 - Qt activation reasons: https://doc.qt.io/qt-5/qsystemtrayicon.html#ActivationReason-enum

Nice! Maybe people will start talking about how the Vorta project is the missing handbook for PyQt ;-) I appreciate the context. Cheers, Nicholas

[m3nu]

Hey all, just got an input by email that we should open the tray menu, when clicking Vorta's system tray.

Currently we show/hide the app and the source code mentions this is "XDG compliant". Just wanted to check if this is the best solution for all desktops? Or would it be better to show the tray menu?

(Question was for XFCE)

[Hofer-Julian]

GNOME doesn't support tray icons at all. IIRC Ubuntu installs an extension to support that. I think most apps open the menu on left click.

[sandrotosi]

I think most apps open the menu on left click.

I do not think that's the case at all, or it may very well depend on the apps you have on your traybar.

In my limited list of apps, running Debian with Gnome and Flashback plugin, i have XChat that opens when left-clicking on it, and Vorta of course.

Other apps open a menu, but that's because their menu allows the user to perform activities: NetworkManager lets you select which connection to enable, the Bluetooth app lets you select which device to connect to.

In case of Vorta, literally the only action is to open the application UI (or quit it). I do not see any benefit in mapping both left and right clicks to open the menu whose only action is to open Vorta.

[m3nu]

Personally, I'd map the tray menu as only action. That's what seems to happen in XFCE and also macOS. Since we already use the XDG_CURRENT_DESKTOP env var, we could adjust the behavior for each desktop?

[sten0]

To add to @sandrotosi and @Hofer-Julian's assessments: KDE Plasma conventions use left click on a "Plasmoid" to pull up a themed menu with a list of actions. Right click usually pulls up a plain menu of configuration-related actions.

GNOME Shell extensions appear to behave similarly, with one difference: the left click menu buttons are large enough to be accessible with fingers on touch screens, and tend to support toggles that can be swiped.

If I remember correctly, macOS (is tray icons or tray app the right word?) are designed to be single-mouse button accessible, with all the primary actions available with a left click. Also, IIRC, holding down the alt or option key can sometimes reveal an alternative menu (presumably for the configuration actions menu)? At any rate, this is in support of "left click opens an most commonly used actions" menu. Following this convention suggests adding additional actions such as "Configure", "Backup Now", "Check Last Archive", etc. The output from such action is handled by the desktop notification handler, which could be tricky, but could be simulated. Are notifications handled similarly on macOS? (eg: backup complete successfully, backup encountered an error, etc.)

But Vorta doesn't use a Plasmoid or GNOME extension at this time, so imho should follow classic tray applet conventions, which were designed for two button (or more) mice. Here left click minimises to tray or restores to tray. @m3nu I'm surprised to hear that XFCE opens a menu on left click, because that's a digression from the ~25 year old convention. Is this also how Transmission (torrent client) behaves? IIRC Transmission has good multi-desktop (and macOS) support, so it's a decent HIG model for a classic tray app.

Oh yeah, there's also Mate (pronounced like yerba mate) desktop, which is a fork of GNOME 2, and which showcases the classic behaviour of left click to minimise|restore to tray, right click for menu. Windows also works this way...at least, up into Windows 8 after which I have no idea.

To be fair, the classic behaviour wasn't designed for one button mice. I like the XDG_CURRENT_DESKTOP idea, but as Vorta won't inherit desktop configuration preferences, I wonder if users non-macOS systems should be able to toggle between both "buttons for the same menu" vs "left click minimises|restores and right click opens menu"?

[sandrotosi]

IIRC Transmission has good multi-desktop (and macOS) support, so it's a decent HIG model for a classic tray app.

i maintain transmission for Debian, and it behaves in the same way i'm advocating here:

• left click: restore/minimize to tray
• right click: menu

[real-yfprojects]

KDE Plasma conventions use left click on a "Plasmoid" to pull up a themed menu with a list of actions. Right click usually pulls up a plain menu of configuration-related actions.

The system tray icons of KGpg, KAlarm and Updates aka Discover behave identical to vorta.
The KDE HIG also states (which was actually pointed out already):

On left click, open the application itself, or a panel that allows quick access to common features.
On right click, open a context menu.

[real-yfprojects]

So what is the conclusion of this thread?

[m3nu]

Good question. XFCE should get a special case I think. Rest works as it is, right?

[real-yfprojects]

Good question. XFCE should get a special case I think.

I think this issue can be closed. Regarding XFCE there is #1206.

Rest works as it is, right?

On KDE the tray menu works as expected. On GNOME it does not work the same because it will open the menu on left and right click while double left click will toggle window visibility but I think this is how GNOME users will expect it to work.