On 2024-05-27 14:01, Ralf Habacker wrote:
Am 26.05.24 um 11:42 schrieb christ...@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
