DBus on Windows - failing Jenkins builds

Hannah von Reth vonreth at kde.org
Sun Feb 2 11:46:34 GMT 2020


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20200202/0672ed42/attachment-0001.html>


More information about the Kde-windows mailing list