DBus on Windows - failing Jenkins builds

[Johnny Jazeix]

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 <vonreth at 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 <jazeix at 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 <vonreth at 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 <bcooksley at kde.org> a écrit :
>
> On Sat, Feb 1, 2020 at 9:51 PM Johnny Jazeix <jazeix at 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