https://bugs.kde.org/show_bug.cgi?id=481870
Simon Redman <si...@ergotech.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Latest Commit|https://invent.kde.org/netw |https://invent.kde.org/netw
|ork/kdeconnect-kde/-/commit |ork/kdeconnect-kde/-/commit
|/7f3287a71b7d1acd30724d05a0 |/bb146a76d06a9039d55661a3e4
|719312a5b8ae94 |fc42176c078643
--- Comment #17 from Simon Redman <si...@ergotech.com> ---
Git commit bb146a76d06a9039d55661a3e4fc42176c078643 by Simon Redman, on behalf
of Rob Emery.
Committed on 22/07/2024 at 21:29.
Pushed by sredman into branch 'master'.
Bluetooth provider workaround for BlueZ/DBus timeouts
Context:
https://invent.kde.org/network/kdeconnect-kde/-/merge_requests/600#note_884500
When bluetooth doesn't exist on the machine at all, QTConnectivity
tries to communicate with Bluez via dbus and introduces a 30 odd second
pause. That's not necessarily a problem in concept, however this blocks
the main thread of KDEConnect, which also then blocks the main thread
of Plasma on logon and causes tremendous delays and very broken
behaviour.
For the life of me, I cannot find a way to do "is bluetooth ok" without
QTConnect kicking off the dbus call so I think the only option is to
thread off the startup of the providers so that pauses don't block
the whole process.
I've just tested this here and my logon with bluetooth missing went
from approx 35 seconds down to about 2.
Ready for input/feedback whenever people have time; in my testing at the moment
it seems to completely break the behaviour of KDEConnect (i.e. things can't
connect), I'm guessing this is something to do with the effect of wrapping
everything in the QThread. I'll dig into that next and see if I can figure it
out.
M +15 -4 core/daemon.cpp
https://invent.kde.org/network/kdeconnect-kde/-/commit/bb146a76d06a9039d55661a3e4fc42176c078643
--
You are receiving this mail because:
You are watching all bug changes.
