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. 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
