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