On 2024-05-26 10:49, Thomas Friedrichsmeier wrote:
On Sat, 25 May 2024 13:02:41 +0200
christ...@cullmann.io wrote:
Now that frameworks is QDBus free on Windows and macOS I would even
propose that in a next update of the stuff we really not have QtDBus
around at all on these systems and make the use optional for the apps
that want to support them.
We go to great lengths to avoid that dbus stuff is ever called, even
deleting the dll and the most freezes you will get if that is not
done is just dbus related.
It would be great if people could join the effort to get that right.
https://invent.kde.org/packaging/craft-blueprints-kde/-/issues/17
Asking mostly out of curiosity, but do you have a link to a writeup /
thread on the problem, and / or suggested replacements? I noticed
before that you were skeptical of dbus on Windows over at kate, but
since it essentially seemed to work for us in RKWard (for the very
limited use-case of reusing a running instance), I never bothered to
follow suit.
Now I see how you replaced dbus for that use-case in kate, and I guess
that'll be easy enough to copy. But if dbus is something to avoid
(where possible) in the interest of present and future cross-platform
compatibility, some generic guidance might be helpful.
I think the guidance is easy:
Beside on desktop Linux or BSD, there
is just no DBus session or system bus running.
Therefore there is nothing to talk to and if you don't ensure yourself
one is properly started (like KDE Connect seems to do) it will just not
work (and more important: makes no sense).
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.
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.
Greetings
Christoph
Regards
Thomas
