same behavior for left and right click on icon tray

[DoctorSubtilis]

I have KDE Neon (last release) and I’m using amule 3.01 from appimage. It works, but the icon tray has a behavior not wholly working.
I mean, left mouse click, that in other apps (included amule 2.3) shows the (main app’s) window, in this release has the same behavior as right mouse click, that is it show not the window, but a pop-up.
Of course in that pop-up there is also "show aMule", but why left and right mouse click should have the same result?
I guess that is a problem of a new release, so I will be patient, but maybe it could be useful to notify this small problem.
Thank you very much!

[got3nks]

Not sure about Windows and Linux, but on macOS this is not the default behavior: left-clicking opens the contextual menu in most apps, at least in all the ones I'm currently using.

I'd like to hear your thoughts, @adem4ik @ngosang @danim7, before changing aMule's systray behavior.

[DoctorSubtilis]

uhm... and right-clicking what does (in MacOS)? Same thing?

[ngosang]

Left click should open the app. Right click should show the menu.

[adem4ik]

Old KDE user here (also ex-Windows XP–10). As I see it, left-click behaviour varies across apps: some show the main window, others open a menu. I have never touched macOS though.

I think it would be better to follow the logic of popular similar apps like qBittorrent, Free Download Manager, Transmission, etc. On KDE and Windows, they work exactly as described in the first post. @got3nks, could you check how they behave on macOS?

As for now my suggestion:

• Apply the proposed logic to Linux and Windows builds.
• Keep the current behaviour for macOS (if it differs there).

[DoctorSubtilis]

To be honest I don’t know a Linux app whose icon tray has the same behavior with left-clicking and right-clicking.
Amule 2.3 had a different behavior with left- and right-clicking...
I think that it is better to keep that difference. In the present situation to show the main Amule window I have to do two clicks (in fact at the beginning of a session even 3: click on the icon tray, then click to Hide Amule, and then to Show Amule: in my opinion a non-sense).
Thank you!

[adem4ik]

@DoctorSubtilis

To be honest I don’t know a Linux app that whose icon tray has the same behavior with left-clicking and right-clicking.

Examples from my machine: Steam, AIMP native beta, GWE. So it is mostly GTK apps; all Qt apps work as you explained. aMule uses GTK too, btw =)

[danim7]

Lol, on my Ubuntu 24.04, both buttons open the context menu for the other few applications I tested. No strong opinion on this, whatever the community decides is good for me :)

[got3nks]

I guess we can go for a split.

MacOS: left-click and right-click both open the contextual menu, this seems to be the standard.
Linux and Windows: left-click show main windows, right-click opens the contextual menu.

[DoctorSubtilis]

It would be perfect, in my opinion (at least for linux)

[got3nks]

Dug into this and the picture is more awkward than it looked.

aMule has two tray backends. CMuleTrayIcon is a wxTaskBarIcon on Windows, macOS, and X11 desktops without appindicator; when libayatana-appindicator3 is found at build time it becomes a StatusNotifierItem and is not a wxTaskBarIcon at all, so the wx click bindings do not exist there. The AppImage and any distro build with the library present use the SNI backend, which is what @DoctorSubtilis is running on KDE Neon.

libayatana-appindicator has no left-click API. Checked against 0.5.94: the complete signal list is new-icon, new-attention-icon, new-status, new-label, connection-changed, new-icon-theme-path, scroll-event, and the only click entry point is app_indicator_set_secondary_activate_target(), which is middle-click. There is no primary activation to hook.

That explains @adem4ik's observation better than "GTK convention" does: those apps behave that way because they use appindicator, and aMule 2.3 differed because it predates the SNI backend.

Current state per platform:

• Windows already does this. Single left-click has toggled show/hide since 3.0.1 (Preview fails to launch Celluloid when using the official 3.0.1 AppImage on LMDE 7 #334).
• macOS already matches what we agreed, left-click opens the menu.
• Linux, SNI backend cannot do it with libayatana-appindicator.
• Linux, legacy GtkStatusIcon backend could, and is the only build the agreed change would alter.

The catch is that the legacy backend is the one we moved away from in b90a593, because wxTaskBarIcon on wxGTK uses GtkStatusIcon, GNOME Shell dropped the legacy notification area in 3.26, and wlroots compositors never implemented it. The icon was silently invisible on Fedora, vanilla GNOME, Sway and Hyprland. So wiring left-click there only helps people whose tray works for the reason that made it broken elsewhere.

In short, on Linux we can currently have a tray icon that is visible on modern desktops, or one that responds to left-click, but not both.

Options:

1. Accept it, and document that left-click opens the menu on Linux as a tray-library limitation.
2. Wire middle-click to show the window via set_secondary_activate_target(). Small and works today, but it is not what was asked for and nobody would discover it.
3. Implement StatusNotifierItem directly over D-Bus with ItemIsMenu=false and an Activate handler, dropping libayatana-appindicator. The only route to real left-click on KDE and GNOME, and a sizeable piece of work: D-Bus service, dbusmenu export, icon serialisation, and the host quirks the library currently absorbs.

[DoctorSubtilis]

Thank you very much.
I’m not a developer, but a simple user...
But ... maybe, could someone in the future find a workaround ?

I add that with Amule 2.3, I had to add this environment setting, to get its tray icon fully working (in wayland): GDK_BACKEND=x11 . But maybe this is off-topic, I don’t know...

[adem4ik]

@got3nks To option 1: DeepSeek pointed out that there's a commit in libayatana-appindicator from 28 April 2026 that implements the Activate method. This might help with the issue. Please take a look:
AyatanaIndicators/libayatana-appindicator@90ce95a

[got3nks]

@adem4ik good find, that changes the answer.

I checked the commit and it is real and released: it is an ancestor of 0.6.0, tagged 2026-06-10. My check was against 0.5.94, which predates it, so "no left-click API" was true of the version I looked at and is no longer true upstream.

The new API is an "activate" GObject signal carrying (x, y), and the fallback is well designed: if a handler is connected the Activate D-Bus method succeeds, and if none is connected it returns an error so the panel keeps showing the context menu. That means we can connect it unconditionally behind a runtime g_signal_lookup("activate", ...) check: left-click works where the installed library is new enough, and nothing changes anywhere else. No build-time version gate, no break for anyone on 0.5.x.

So option 3 is off the table, which is good news. What is left is getting 0.6.0 in front of users, and for our own bundles that is on us:

• Flatpak builds libayatana-appindicator from source and pins 0.5.94, one tag below the fix. Bumping that pin is a one-line change.
• AppImage currently takes 0.5.90 from Ubuntu 22.04's apt, so it needs a from-source build instead. The Dockerfile already does exactly that for libupnp, since 22.04 only ships the ancient 1.8.x line, so the pattern is there.
• Distro packages are the only ones we cannot move. Ubuntu 24.04 LTS is on 0.5.93, so those users wait for their distro.

@DoctorSubtilis so this is fixable for the AppImage, not just in theory: it needs the aMule-side signal handler plus building 0.6.0 into the AppImage.

[adem4ik]

libayatana-appindicator 0.6.0 is already available in Arch, CachyOS, Manjaro, and Debian Experimental. You can see the full list of distributions and their versions here: https://repology.org/project/libayatana-appindicator/versions

P.S. I can help with functional testing on CachyOS and Manjaro if needed =)

[got3nks]

@DoctorSubtilis @adem4ik this is in master now (#1200) and there is an AppImage to try.

Build artifacts from the packaging run: https://github.com/amule-org/amule/actions/runs/33188814719

Take appimage-x86_64 (or appimage-aarch64 on ARM). GitHub only serves workflow artifacts to logged-in users, so open it while signed in or the link will look broken. It downloads as a zip containing the .AppImage; chmod +x it after unzipping.

What to check:

• left-click on the tray icon should now show the main window, and hide it again if it is already visible, the same as Windows
• right-click should still open the context menu, unchanged

This AppImage bundles libayatana-appindicator 0.6.0, so it does not matter what your distro ships. I confirmed the bundled library is the new one rather than trusting the build: it contains the Activate handler that only exists from 0.6.0.

Worth saying plainly: nobody has actually clicked this yet. The code path is verified and the library is confirmed bundled, but 0.6.0 is too new for any distro to package, so this is the first real test. If left-click still opens the menu, the interesting detail is whether your desktop sends Activate at all, which differs between KDE and GNOME's AppIndicator extension.

Distro-packaged builds will pick this up when their libayatana-appindicator reaches 0.6.0. Ubuntu 24.04 LTS is still on 0.5.93.

[adem4ik]

Smoke-tested on CachyOS KDE using amule-git build — works great. Many thanks!

2026-08-28.20-41-10.mp4

Later I'll check some more combinations (appimage, Manjaro KDE/Xfce, distributions with pre 0.6.0 libayatana-appindicator versions).

[DoctorSubtilis]

Hello everybody. Any news about a new release of a Linux Amule with the above changes?
I appreciate your work, and I don't want to rush you. Just to know if the work is progressing...
Thank you very much! 🙂

[got3nks]

Hello @DoctorSubtilis, the release is expected next week or shortly after.

[DoctorSubtilis]

Thank you very much! Wonderful!