DBus on Windows - failing Jenkins builds

Ben Cooksley bcooksley at kde.org
Sat Feb 1 17:36:23 GMT 2020


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


More information about the Kde-windows mailing list