Hi, sorry for the direct forward.
TLDR: Notifications uses dbus. On Windows and Mac, there is no dbus so classes using dbus are not compiled. But KStatusNotifierItem still uses dbus internally and this causes link error. Is there a clean and easy way to bypass dbus calls for Windows? Johnny ---------- Forwarded message --------- De : Ben Cooksley <bcooks...@kde.org> Date: mer. 12 févr. 2020 à 10:17 Subject: Re: DBus on Windows - failing Jenkins builds To: KDE on Windows <kde-wind...@kde.org> On Mon, Feb 3, 2020 at 8:15 PM Johnny Jazeix <jaz...@gmail.com> wrote: > > Thank you Hannah for the addition, > > It now affects also skrooge and kwordquiz :/ (maybe more soon when > they will be compiled again). > > I can try to find some time during the month and take a look to add > these ifdef, if nobody fixes it before. Another option is to raise this on KDE Frameworks Devel, as someone there may know of an easy way to shortcut the D-Bus code in KSNI. Cheers, Ben > > Johnny > > Le dim. 2 févr. 2020 à 12:46, Hannah von Reth <vonr...@kde.org> a écrit : > > > > I had another look. > > It looks like we need to add a couple of ifdefs to > > https://github.com/KDE/knotifications/blob/master/src/kstatusnotifieritem.cpp > > There is no point in using dbus on Windows or mac here, as there is no > > desktop service that could receive it.... > > > > > > On 01.02.20 18:36, Ben Cooksley wrote: > > > > On Sun, Feb 2, 2020 at 1:53 AM Johnny Jazeix <jaz...@gmail.com> wrote: > > > > The applications link to KF5Notifications.lib library, the issue is > > that this one does not compile KStatusNotifierItem class because it's > > in a conditional if in the CMakeLists.txt of KF5Notifications. > > > > Which is the correct behaviour as we want a version without D-Bus. > > > > Unfortunately though that means every KDE application that wants to > > provide a system tray icon will fail to compile, as we use KSNI for > > that. For systems that don't mind having dbus around at runtime, it > > isn't an issue as KSNI will fallback to QSystemTrayIcon. We of course > > don't want DBus at all (even at runtime), so it seems to me that the > > necessary fix is for KSNI on Windows to skip all the DBus stuff and > > just provide it's wrapper functionality. > > > > The same should probably apply on macOS. > > > > Thoughts? > > > > Cheers, > > Ben > > > > Le sam. 1 févr. 2020 à 13:15, Hannah von Reth <vonr...@kde.org> a écrit : > > > > Directly linking to KStatusNotifierItem sounds wrong. > > > > It should probably use the normal knotifications api. > > > > > > Cheers, > > > > Hannah > > > > > > On 01.02.20 12:49, Johnny Jazeix wrote: > > > > Le sam. 1 févr. 2020 à 09:57, Ben Cooksley <bcooks...@kde.org> a écrit : > > > > 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? > > > > It may be something to discuss on kde-devel (or directly with the > > corresponding teams) because I don't know much about the use of the > > library in the applications. > > > > KStatusNotifierItem is not used a lot on drkonqi: > > https://github.com/KDE/drkonqi/search?q=statusnotifier&unscoped_q=statusnotifier > > so it should not be complicated to bypass it on Windows but it seems > > to require more efforts for ruqola. > > > > Johnny > > > > > > Johnny > > > > Do you have any input on this? > > > > Johnny > > > > Cheers, > > Ben
