Open wxtrac opened 6 years ago
Perhaps this (from the GTK docs) is relevant?
gtk_status_icon_set_tooltip_text has been deprecated since version 3.14 and should not be used in newly-written code.
Use notifications
I did some research into the topic and found the following:
There are two Freedesktop.org specifications related to system tray icons: an older, XEmbed-based one, and a newer one called StatusNotifierItem.
GtkStatusIcon implements the XEmbed-based spec.
Plasma 5 has dropped support for the XEmbed-based spec. It only supports StatusNotifierItem. (They do have a shim called xembed-sni-proxy - this is why the system tray icon created with GtkStatusIcon shows up at all. However, it's buggy when used with GTK3, hence the contextmenu and tooltip issues (some discussion of that here).)
GTK has deprecated GtkStatusIcon and removed it in GTK4. I'm not aware of any plans to support StatusNotifierItem in GTK itself, possibly because newer versions of GNOME Desktop don't have a system tray. (The "notifications" that the deprecation message suggests using, refers to a conceptually different feature: transient notifications triggered by events, rather than a persistent icon.)
Nonetheless, GTK-based applications can interface with a desktop environment that supports the StatusNotifierItem spec. Two libraries used for this purpose are libappindicator and statusnotifier. Of the two, libappindicator seems the more popular (shipping in popular distributions).
So, it seems wxWidgets could support the StatusNotifierItem spec, either by using libappindicator (making it an optional dependency), or by implementing the spec itself (based on a brief glance at the libappindicator implementation, it involves sending some D-Bus messages).
Apparently xembed-sni-proxy has been fixed in Plasma >= 5.10 ([1], [2]), though I can't test that myself since I use Debian stable which is stuck on 5.8.
Of course, wxWidgets should still aim to migrate to StatusNotifierItem at some point, as xembed-sni-proxy and GtkStatusIcon will eventually go away.
[1] https://bugs.kde.org/show_bug.cgi?id=362941 [2] https://bugs.kde.org/show_bug.cgi?id=375017
It would, of course, be great to migrate to newer API, but I've never used neither libappindicator nor statusnotifier and I have no idea which one to use and whether it provides enough functionality to implement the existing API.
If anybody could look into this and provide at least a plan of action (and ideally a patch...), it would be very, very welcome.
Just as an FYI, this issue still occurs in Plasma 6. At least with regards to the tooltip. I got the context menu to appear by handling wxEVT_TASKBAR_CLICK and calling wxTaskBarIcon::PopupMenu().
FWIW I think using libayatana-appindicator might fix this, at least my understanding is that this is what is used for working taskbar icons under Linux nowadays — even though I haven't tested it under KDE myself (if anybody is interested, they have a simple example which can be compiled with just a single gcc command to check if it works as expected on your system).
Issue migrated from trac ticket # 18081
component: wxGTK | priority: normal
2018-02-12 02:01:29: HighCommander4 (Nathan Ridge) created the issue
Originally reported here.
After upgrading my desktop environment from KDE Plasma 4 to KDE Plasma 5, the behaviour of taskbar icons has regressed:
The tooltip passed as the second argument to wxTaskBarIcon::SetIcon() no longer appears when hovering over the icon. Instead, the application executable's filename is shown in the tooltip.
Right-clicking on the icon no longer shows the context menu created by an overridden wxTaskBarIcon::CreatePopupMenu().
These problems can be reproduced in the 'taskbar' sample.
My GTK version is 3.22.