Migrating Windows CI to Qt 6.7 - Roadblocks

christoph at cullmann.io christoph at cullmann.io
Mon May 27 13:26:19 BST 2024


On 2024-05-27 14:01, Ralf Habacker wrote:
> Am 26.05.24 um 11:42 schrieb christoph at cullmann.io:
>> 
>> For the re-use of instances you need to use something like
>> 
>> https://github.com/KDAB/KDSingleApplication
>> 
>> or similar.
>> 
>> Any implicit starting of the dbus stuff will often just result in 
>> hangs
>> or other misbehavior.
> 
> DBus on Windows starts automatically when a client requests a dbus 
> connection, so there is only a problem if dbus-daemon and the required 
> configuration files were blacklisted during packaging and are not 
> included in the installation. I have never had problems with this when 
> working with KDE applications using MinGW.
> 
>> 
>> It is just like X11: don't use it on systems that don't have it as
>> native windowing system, we guard that the same way.
>> 
> There is a big difference to X11. X11 is usually not distributed with 
> KDE applications as it can be with dbus, as there is a corresponding 
> package in Craft.

That is just the same, it is foreign to the system you target.

There is no concept of DBus for communication with other apps or the 
system on non Linux/BSD desktop systems.
That we bundle it is just an ugly workaround for all the things that 
non-conditionally used it.

> 
> There is e.g. the remote control area which is implemented in KDE 
> applications with dbus. Should we now use a separate implementation for 
> each platform with additional effort, although there is a 
> platform-independent solution ?

Yes,

if you want that to work properly on other systems, one need to use the 
matching IPC services they provide.
Or just not do it.

For most use cases something like 
https://github.com/KDAB/KDSingleApplication is enough and avoids any 
extra spawned processes.
Naturally that is not true for all usages.

Greetings
Christoph


More information about the kde-devel mailing list