v1cont / yad

Yet Another Dialog
GNU General Public License v3.0
685 stars 57 forks source link

--text option for --notification mode not worked #246

Open x09 opened 1 year ago

x09 commented 1 year ago

simple demo

yad --notification --text="ssss"

i expected tooltip with 'ssss', but see 'YAD' only

if a send 'tooltip:ssss' to pipe a get nothing too, 'YAD' only everytime.

p.s. KDE. yad (versions 7.3 and 12.3 )

de-vri-es commented 1 year ago

The command yad --notification --text="sssss" works to set the tooltip in 13.0.

vimpostor commented 7 months ago

I investigated this issue and it turned out to be quite the rabbithole. In the end I had to debug quite a lot of large scale codebases, including GTK, Qt, libxcb and KDE Plasma. There also is a very similar issue in wxWidgets: https://github.com/wxWidgets/wxWidgets/issues/18081

The tl;dr is: Yad is not at fault for this issue. The issue is partly in KDE Plasma, but mostly in GTK3 and there is no hope left for fixing it upstream in GTK.

So, yad uses GTKStatusIcon to display the icon in the system tray. Internally GTKStatusIcon uses GTKTrayIcon, which uses the very old XEmbed System tray spec.

KDE Plasma initially dropped support for XEmbed system tray icons in favor of the much newer StatusNotifierItem spec (short: SNI). However, they readded support for XEmbed tray icons later by adding a XEmbed->SNI proxy bridge which takes over the job of the old XEmbed server part and translates over all XEmbed icon events to SNI icon events, so that KDE Plasma understands them (which is why you see a yad statusicon at all).

The bridge is very very hacky and does some really bespoke stuff like translating mouse click events, but in my eyes this is arguably a true testament to how extensible X11 is. The sniproxy bridge is unfortunately missing support for the Balloon messages part of the XEmbed systemtray spec, which means that it will not translate hover event popup messages to SNI.

This is what I meant with the issue is partly on KDE's site, but it would be very easy to fix: Just add an extra case for SYSTEM_TRAY_BEGIN_MESSAGE here and handle the message according to the XEmbed systemtray spec. Then afterwards the SNI tooltip can be set to the received message.

Turns out, there is more to the issue: GTKTrayIcon does not even send the balloon style message according to the XEmbed systemtray spec. There exists code for it, but it is never actually called. Instead what GTK3 does, is to use its own hover logic on the icon (since it's a normal X11 window), which then shows a normal GTKTooltipWindow containing the tooltip. Unfortunately it is pretty impossible to intercept that (or at least very hacky), so we can't translate that to SNI events.

So why am I saying GTK3 all the time? The GTK devs have gone completely haywire in the meantime and declared the system tray to be a feature that noone needs. Thus in GTK4 there no longer is a GTKStatusIcon, nor is there a GTKTrayIcon (because who needs basic features in a GUI toolkit). This means that going forward it is impossible to fix the problem in GTK (i.e. either by moving over to the new SNI spec, or by rewriting the XEmbed systemtray codepath to use the balloon messages).

So in the end, it looks like there is no way to fix this problem (other than maybe reimplementing true XEmbed systemtray support in KDE Plasma without the sniproxy bridge, but that is not really worth it, given that noone uses the old spec anymore).

Why did I not at least contribute the balloon message support to the sniproxy bridge in KDE Plasma? Well, I searched entire Github and major toolkits for usage of XEmbed balloon message, and it seems that noone significant is using it anyway. It's a deprecated spec that is already replaced, not even Wine uses balloon messages (although they still use the old spec in general, but just display custom balloons without the spec, similar to GTK3. But there is a merge request to move Wine over to SNI completely).