On Sat, Feb 1, 2020 at 9:51 PM Johnny Jazeix <jaz...@gmail.com> wrote: > > Hi,
Hi Johnny, > > There are some builds in Jenkins that fail because of unresolved > external symbol of KStatusNotifierItem class (and let's be fair, I > don't like failing Jenkins). > After digging a bit, it is due to the fact that KNotifications is > built without dbus support: > https://cgit.kde.org/knotifications.git/tree/CMakeLists.txt#n42 > meaning kstatusnotifieritem.cpp is not compiled: > https://cgit.kde.org/knotifications.git/tree/src/CMakeLists.txt#n24 Aha. I had seen a few of these KSNI symbol failures, so it's nice to know why they're occurring. > > However dependencies (drkonqi and ruqola if I'm not wrong), don't have > a condition on Windows for DBus use and directly use the > KStatusNotifierItem class. > > I'm not sure on the support of DBus on Windows and what is the right > direction to go: > * either enable dbus on KNotifications for Windows (if it is supported). > * or disable dbus on Windows on programs that uses it (drkonqi and ruqola).. Given that D-Bus doesn't really belong on Windows, doesn't bring us much in the way of benefits there (as users are using just a single application in many cases), and has tended to cause false positives with anti-malware products, i'd suggest we follow the path of disabling dbus support. Of course that brings up the question of whether KSNI should exist at all on Windows. If memory serves it provides support for system tray icons, in which case it probably should just wrap around the appropriate Qt classes (for which I think fallback code already exists?) and not compile any of the D-Bus stuff. Thoughts? > > Do you have any input on this? > > Johnny Cheers, Ben
