David Edmundson wrote:
> You missed reading the code that calls this in > src/widgets/util/qsystemtrayicon_x11.cpp which will make an X system tray > if the platform doesn't. Indeed, but that's curious. I see what you mean, but I followed the flow in a debugger and AFAICT the qpa_sys==NULL path was never taken (which is why I missed it). I'll have to take another look at that. > Please don't tell me you're using the Plasma platform integration plugin > under XFCE? Why wouldn't one do that? It's not plasma-specific in the sense that it doesn't depend on anything that the plasma environment provides. In fact you get close to the same functionality when you set the proper env. variables thanks to qgenericunixtheme.cpp . FWIW, I'm only using XFCE on that machine because it's so much cheaper to build than a full Plasma environment. For the rest I want my Qt/KF5 apps to behave like they would under Plasma5 - not unlike running KF5 applications under a Plasma4 environment in fact. I know that the integration plugin modifies the systray behaviour but it's not the only one responsible for KDE apps not getting a systray under XFCE. KNotifications also seems to have its part of responsibility, judging from the following: - I use xfwm4 and xfce4-panel under XQuartz on my Mac and installed dbusmenu-gtk and the sni-plugin there too - I maintain a fork of the plasma integration plugin for Mac (osx-integration) - I added the SNI notifier widget to the XFCE panel - Qt/Cocoa applications not using KNotifications still use the native Mac systray - KDE4 and KF5 applications start using the XFCE systray as soon as I activate it and revert to the native systray when I unload the XFCE sni plugin. - For KF5 applications this is independent of the integration plugin, i.e. it happens with or without that plugin. This would happen if KNotifications tests for presence of a SNI host on the DBus and uses native systray functionality only as a fallback. I'll be looking into that too today. R.