System tray icons applications don't recieve wheel (probably also tooltip) events

[redtide]

Expected Behavior

A X11 Qt application using QSystemTrayIcon should recieve QEvent::ToolTip and QEvent::Wheel events.

Current Behavior

No events, except deferred delete on an attached eventFilter.

Possible Solution

IDK.

Steps to Reproduce (for bugs)

Debug an application using QSystemTrayIcon that has an eventFilter on it,
it should call it only on deferred delete.

Context

I wrote a standalone application based on lxqt-panel volume plugin that can run alsamixer from QTerminal and use ALSA' normalized/linear volume. Now I want to control the volume by
rotating the mouse wheel over the tray icon like in the original plugin, but this works only under Tint2 system tray, (I haven't tried others).

See qtilities/voltrayke#3.

System Information

• LXQt Version: 1.3.0
• Distribution & Version: Archlinux
• Qt Version: 5.15.10
• liblxqt Version: 1.3.0 git

[tsujan]

I always assumed that ineffectiveness of wheel scrolling over Audacious's tray icon was a bug in Audacious. But it may be related to this report.

probably also tooltip

Tooltips are OK here — I say this as a user, not remembering the code and not having time to reread it for now.

[redtide]

Tooltips are OK here

Tooltips are displayed but I meant that are not captured in eventFilter as events, though IDK how they are supposed to be used.
It's in the documentation link, latest lines:

Only on X11, when a tooltip is requested, the QSystemTrayIcon receives a QHelpEvent of type QEvent::ToolTip. Additionally, the QSystemTrayIcon receives wheel events of type QEvent::Wheel. These are not supported on any other platform.

[tsujan]

The doc talks about two protocols: X11 XEmbed (legacy/obsolete), and the DBus-based tray icons. I think by "Only on X11" it means the obsolete one, which it still supports.

Just now, I logged into KDE and saw that Audacious's tray didn't respond to wheel scrolling either. So, this may not be a bug on our side, exactly because it's limited to the legacy protocol.

BTW, it's good to see that Qt doc mentions LXQt alongside KDE and Gnome :)

[redtide]

The doc talks about two protocols: X11 XEmbed (legacy/obsolete), and the DBus-based tray icons. I think by "Only on X11" it means the obsolete one, which it still supports.

I see. Well, it kinda sucks that the only one supporting it is on an old implementation, it's useful having the tray icon responding to mouse wheel. So basically it can work only for panel plugins buttons.

EDIT: I can't see where it talks about the DBus one, can you please point me to it? I'm kinda blind 😝

Just now, I logged into KDE and saw that Audacious's tray didn't respond to wheel scrolling either. So, this may not be a bug on our side, exactly because it's limited to the legacy protocol.

Ok, so I can close this I guess. Would be nice if DBus could support this but I can imagine it may be too much to respond to many, fast wheel events.

BTW, it's good to see that Qt doc mentions LXQt alongside KDE and Gnome :)

Oh, nice! I didn't notice it!

[redtide]

I see a Scroll method in the D-Bus implementation, can't be this called from a handleWheelEvent function?

[tsujan]

I don't know, but I ask myself, "if it was possible, why didn't KDE implement it?" ;)

EDIT: Also, see GNOME's new proposal: lxqt/lxqt#2295. It's getting like a jungle ;)

[redtide]

or why Qt doesn't support it in QSystemTrayIcon via QDBusInterface?

It's new stuff to me, so I have no much of an idea, but if it works via DBus I don't understand how it could be X11 specific.

[tsujan]

Ok, so I can close this I guess...

It would be nice if you could test your app under KDE too (I guess GNOME doesn't have any tray, and I'm not sure about XFCE's implementation when it comes to Qt).

[redtide]

No luck today: I installed plasma-desktop package, though I don't like KDE and the app crashes there. I need also to redo the QtC configuration which is too old, the debugger is messed up.
Hope I can give some feedback soon.

[tsujan]

though I don't like KDE and the app crashes there.

I understand, but, IMHO, KDE may be needed for testing Qt apps thoroughly. I have a full installation for that reason.

[redtide]

That's right.
To me QSystemTrayIcon is a problem, I had some crashes before and it's not easy to understand why they happen: the backtrace in QtC is not helpful and it happens in strange ways: sometimes having the app initialized with a different sequence and sometimes I have to show and then hide its context menu. I'm so tempted to try to create a dummy one with a transparent icon, get its rect and put over it a flat QToolButton.

[tsujan]

...get its rect and...

I'm afraid QSystemTrayIcon::geometry() gives you an empty rectangle — unless under some special circumstances, which I've forgotten (as usual).

[redtide]

What do you mean by empty? It doesn't returns the x y w and h of it in the screen coordinates as stated in the docs?

[tsujan]

No, it didn't when I wrestled with it years ago; it was useless.

Whether things have changed since then, I don't know, but I concluded that there was no way to know the rectangle because it belonged to the tray, not to the app.

[redtide]

Then it's really a total crap of API.

[tsujan]

I don't agree. With the old protocol, the tray menus were those of the apps, and so, they might be alien. With the "new" one (which isn't new anymore), all menus are native.

[redtide]

how you call random crashes and a geometry() function that doesn't returns what it should then?

[tsujan]

As for geometry(), I told my theory (please try it; I'm curious to know if something has changed). As for probable crashes, they could and should be fixed ;)

EDIT: Never mind; I tested with FeatherNotes and Qt6, and geometry() returned a null rectangle, as expected.

[redtide]

I did:

• created an empty cmake project
• copied the code from the old qmake systray example
• added the eventFilter and tested with Tint2

it doesn't work neither under KDE. I haven't investigate much but it seems that geometry() should return something if those sys or qpa_sys are not null and the icon is visible, but IDK what is that all about.

[redtide]

@tsujan I started my app from terminal and moving the wheel over it, forgetting for a moment about this issue. I only have it and NM applet active and moving the wheel over the tray (over both) I got some debug messages, so I did a search in lxqt-panel code and found this:

Received click 4 with passed x*y 0 0
Received click 5 with passed x*y 0 0

4 when moving the wheel down and 4 up. Could this be useful in any way?

[tsujan]

Could this be useful in any way?

Maybe. But I have no knowledge of (or don't remember) that code. It seems that it was adapted from KDE.

[redtide]

so I did a search in lxqt-panel code and found this

I haven't realized that SNI stands for StatusNotifierItem: here the link to the interesting part, Scroll. In the link above I haven't noticed that that debug message is called few lines above by a Scroll function (line 529, @palinek work).

I'm afraid QSystemTrayIcon::geometry() gives you an empty rectangle — unless under some special circumstances, which I've forgotten (as usual).

Is this related? (@paulolieuthier work)

The LXQt plugin implements SNI Scroll but I'm not sure how these are related and so how eventually use them from a client application; I haven't found yet an example at least how to do it via QDBus.

[tsujan]

Is this related? (@paulolieuthier work)

You're finding interesting things in those codes! A problem LXQt inherited from KDE, or just something that wasn't possible for some reason? Hopefully @palinek and @paulolieuthier could shed some light on this.

EDIT:

According to the code comment, it may be the latter: // StatusNotifierItem doesn't provide the geometry

[redtide]

According to the code comment, it may be the latter: // StatusNotifierItem doesn't provide the geometry

yes, that's what I wanted to point out with my "this related" link.
I guess it is not much an issue, I might use the cursorpos or just make some "overlay popup", important is having the wheel delta and source information.

Now I just noticed that I have 2 plugins for the tray, one (tray) is for the old xembed based applications and one for the new ones (statusnotifier). Trying to disable one makes vanish one of my QSystemTrayIcon based application (the volume control I did based on volume plugin) while another (a JACK control settings interface I made) is on the statusnotifier.
But I don't understand which code made this happen to be implemented in one or the other way, I used the same class? Is there any documentation about this?

[tsujan]

What I can say for sure is that a tray icon made by using purely Qt methods doesn't need the obsolete X11 XEmbed protocol and works everywhere. Wayland isn't just a possibility nowadays.

[redtide]

I have no X11 dependencies in both applications, the volume tray app is basically a standalone version of LXQt panel' volume plugin with additional fixes to make work alsamixer as external mixer application and a linear, normalized volume using ALSA (like other volume controls do like PNMixer).

The wheel event works on xembed based panels like tint2, but just by applying an event filter
to the tray icon, not using X11 code.

The only difference is that the other one depends to QDBus, but for unrelated reasons: it wraps to a custom dbus service to monitor when the jack application is running and forward its log.

I should investigate the qt code to understand the logic.

[sebholt]

Modern system tray bars use the https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/ DBus interface to setup icons. Qt's QSystemTrayIcon does not implement the Scroll event properly.
There already is Qt bug (please upvote): https://bugreports.qt.io/browse/QTBUG-91697

Other applications have the same issue:

• QasMixer: https://gitlab.com/sebholt/qastools/-/issues/2
• Audacious: https://redmine.audacious-media-player.org/issues/960

[tsujan]

I reopen this with "Qt bug" label just for tracking the Qt bug report more easily.

@sebholt, thanks for the link!

[redtide]

There already is Qt bug (please upvote)

upvoted, I'm still curious to know if this thing is managed somewhere in KDE (but not that much to reinstall plasma :P ).

[tsujan]

I'm still curious to know if this thing is managed somewhere in KDE

It isn't. → #1925 (comment)

[sebholt]

KDE has two system tray icon classes,

• KSystemTrayIcon: https://api.kde.org/frameworks/kdelibs4support/html/classKSystemTrayIcon.html
• KStatusNotifierItem: https://api.kde.org/frameworks/knotifications/html/classKStatusNotifierItem.html

The former derives from QSystemTrayIcon and doesn't support wheel events.
The latter wraps around a DBus based implementation of
https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/
and supports wheel events.

I suppose the icons that support wheel events are based on KStatusNotifierItem.

[tsujan]

As I said, I just launched Audacious and saw that mouse wheel didn't work with its tray under KDE either.

The latter wraps around a DBus based implementation of

That's what LXQt does too.

[redtide]

@tsujan: Is it possible that audacious is using XEmbed?
If so maybe some other application could work using the SNI API under KDE;
@sebholt seems confirming that there is a dedicated SNI API, and LXQt has one too (I mean the one I "discovered" made by paulolieuthier).

I think this bug could be fixed from LXQt side without caring about what Qt or KDE does if it's based on a protocol on top of DBUS, by catching related messages directly.

[tsujan]

Is it possible that audacious is using XEmbed?

Nope! I'm under Wayland (LXQt+LabWC+Waybar) and there's no difference with Waybar's tray. The results of my test codes were the same too.

[sebholt]

I just discovered QDBUS_DEBUG from here: https://doc.qt.io/qt-5/qtdbus-index.html
When I start qasmixer (my Qt based alsamixer) with
QDBUS_DEBUG=1 qasmixer
and then spin the mouse wheel over the tray icon, it clearly shows the DBus Scroll message.
Only the QSystemTrayIcon doesn't make any use of it :(.
I'm on KDE/Wayland btw..

[redtide]

it clearly shows the DBus Scroll message.

do you mean something like this?

QDBusConnectionPrivate(0x7efd440178c0) got message (signal): QDBusMessage(type=MethodCall, service=":1.14", path="/StatusNotifierItem", interface="org.kde.StatusNotifierItem", member="Scroll", signature="is", contents=(-120, "vertical") )

(120 or -120 as values only here, with my own VolTrayke volume control app)

[sebholt]

do you mean something like this?

Yes, exactly.

I get +/- 120 as well.

[sebholt]

It seems the 120 are eighths of a degree, so 15 degrees.
That's according to https://doc.qt.io/qt-6/qwheelevent.html
See QWheelEvent::angleDelta there.

[redtide]

FTR I made a SNI client example simulating a volume control, the only thing I'm not able to make work yet is the volume tooltip when using the wheel (I replaced it with a notification message temporarily).

I used the SNI code from lxqt-qtplugin with some updated code for libdbusmenu-qt from KStatusNotifierItem, might be interesting having some API (a sni library?) instead.

Note that current libdbusmenu-qt6 in Arch seems not working, here at least didn't.

[redtide]

@tsujan I think would be nice to have lxqt SNI as library extracted from qt plugin (plugin-statusnotifier seems to have more code though) like it is for kstatusnotifieritem in Arch for KDE.

Also it seems that the libdbusmenu-qt library required by the above lxqt-panel plugin and in lxqt-qtplugin is not working for qt6 (the one in Arch seems broken even if they patched it, no context menu) and it could possibily be bundled from the one bundled in kstatusnotifieritem instead using it as dependency (it's no more maintained).

Meanwhile I sent a mail to Paulo Lieuthier asking some info about it.

[tsujan]

... is not working for qt6

You need the latest Qt6 branches. It works here.

For the rest, @palinek is the expert. Frankly, I don't see any problem other than that Qt bug, which isn't our job to fix.

[tsujan]

Note that current libdbusmenu-qt6 in Arch seems not working

And we don't use it anymore. See lxqt/lxqt-qtplugin@8e8a2b3

[redtide]

... is not working for qt6

You need the latest Qt6 branches. It works here.

libdbusmenu-qt6 in Arch is not working.

For the rest, @palinek is the expert. Frankly, I don't see any problem other than that Qt bug, which isn't our job to fix.

There is no problem (except is not clear how to use tooltips in lxqt SNI), it's just that by having a library for SNI, clients can use it to write applications that uses that protocol instead depending by KDE stuff.

[redtide]

Note that current libdbusmenu-qt6 in Arch seems not working

And we don't use it anymore. See lxqt/lxqt-qtplugin@8e8a2b3

I didn't even know there was a libdbusmenu-lxqt, nice!

[tsujan]

I didn't even know there was a libdbusmenu-lxqt, nice!

@stefonarch and I use the Qt6 branches since they were made (we also use them under Wayland).

[redtide]

Not following fully LXQt development nor Wayland switch to labwc here yet.
BTW statusnotifier plugin should also be updated to use libdbusmenu-lxqt.

[tsujan]

BTW statusnotifier plugin should also be updated to use libdbusmenu-lxqt.

libdbusmenu-lxqt is only for Qt6; lxqt-panel has no Qt6 branch yet (waiting for a stable version of KF6, which should come soon, and also a really usable layer-shell-qt6 with Wayland).

[redtide]

I wonder why DE developers only fork stuff internally instead maintain the original, so now there are a LXQt fork and a bundled one in KDE useless for other people.

[redtide]

I forgot to mention that IIUC the XEmbed protocol should be supported by plugin-tray as a proxy to SNI, but unless it's not the case, it seems it's not working for some reason.
@sebholt thoughts?

[tsujan]

Although our main problem was the lack of a stable libdbusmenu-qt6, we might also be enable to fix its probable problems (like #1417) or work around Qt's issues (like #1802) in our fork.

And XEmbed protocol is a relic of old times; new codes shouldn't go near it or anything based on X11.

[sebholt]

@redtide

And XEmbed protocol is a relic of old times; new codes shouldn't go near it or anything based on X11.

Agreed.

[tsujan]

As for libdbusmenu-lxqt, it might have been needed even with Qt5 — see the last paragraph of #1417 (comment). However, we'll say goodbye to Qt5 soon.

[redtide]

Yes, and those issues are also a reason more to work on a common project instead doing forks anywhere, so a single new libdbusmenu-qt repository for both LXQt and KDE devs would be the perfect solution.

@sebholt made me notice that there is no libdbusmenu-qt6 in Debian and the one in Arch is a patch over the old code that doesn't work here. I extracted the code from KStatusNotifierItem repository and works with both Qt5 and Qt6. About the submenu bug IDK if they fixed it already.

[tsujan]

those issues are also a reason more to work on a common project instead doing forks anywhere

Maybe, in an ideal world. But, again, we would have to wait a long time before porting our main libraries to Qt6. IMHO, libdbusmenu-lxqt is a good balance between depending on others' works (KDE FrameWorks) and doing one's own work.

[redtide]

@tsujan FTR: feel free to close this at any time when you will no need to track the QSystemTrayIcon bug, to me this is solved by using our SNI library (should be made public soon-ish), which derives by both LXQt code and KSNI.