QString or QStringList then it blows up with:
/home/rob/kde/src/kdeconnect-kde/kcm/kcm.cpp: In constructor ‘KdeConnectKcm::KdeConnectKcm(QObject*, const KPluginMetaData&, const QVariantList&)’:
/home/rob/kde/src/kdeconnect-kde/kcm/kcm.cpp:82:17: error: ‘class DaemonDbusInterface’ has no member named ‘linkProviders’
82 | daemon->linkProviders(),
even though the signatures are correct etc. No idea, I'll have
to fix this ultimately but I'll workaround it for now
It looks like this has never worked under QT6, the implementation was inconsistent with the QT5 behaviour. Given that the QT5 behaviour works with the shipped Android app, I've tweaked the QT6 to be functionally equivalent to the QT5 implementations.
https://invent.kde.org/network/kdeconnect-kde/-/merge_requests/600#note_1018493
@diamnew if you are able to build and test this; that would be a great help.
Moves all the stuff that is needed to start DBus on macOS (which for some reason it needs several steps, involving the use of `launchctl`) into a single `startDBusDaemon()` function. Before, it was spread into `kdeconnectconfig.cpp`, `indicatorhelper_mac.cpp` and `dbushelper.cpp`.
It also removes checking for an existing DBus daemon and always starts our own, since in most cases we couldn't connect to it anyway. This, together with removing the sleep in the retries when polling for the DBus daemon from 3s to 100ms, makes the startup much faster, so I removed the loading splash screen.
We don't need to convert the data to an intermediate QVariantMap just to
make JSON out of it. This siginificantly improves performance.
The measurements were done with 3000000 iterations each:
Before serialization: 0.0045009 msecs
Before deserialization: 0.002293 msecs
After serialization: 0.0034216 msecs (32% faster)
After deserialization: 0.001776 msecs (29% faster)
Auto reconfiguration of own certificate:
currently:
if kdeconncectd loads its certificate and its expired or not effective yet
it generates a new certificate
previously:
if kdeconncectd loads its certificate and its expired or not effective yet
it continues having the same certificate
This brings forth an issue: Other devices would refuse to connect to a device with
an expired or non-effective certificate.
Auto-delete of orphan certificates:
currently:
Devices in kdeconnectd's devicelist that have illegal ssl certificates
(expired, not effective yet, empty) get automatically deleted from the
devicelist
previously:
they would just exist forever until the user deletes them
A year does not have 356 days:
currently: int a_year_in_seconds = 365 * 24 * 60 * 60;
previously: int a_year_in_seconds = 356 * 24 * 60 * 60;
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.
BUG: 481870
## Summary
Fix Bluetooth branch build errors for changes in !678
## Test Plan
### Before:
Build errors in bluetoothlinkprovider.cpp due to undefined variable and due to incorrect argument type.
```
/home/simon/src/kdeconnect-kde/core/backends/bluetooth/bluetoothlinkprovider.cpp:301:56: error: cann
ot convert ‘NetworkPacket’ to ‘NetworkPacket*’
301 | if (!success || !DeviceInfo::isValidIdentityPacket(receivedPacket)) {
| ^~~~~~~~~~~~~~
| |
| NetworkPacket
<snip>
```
### After:
Clean build.
Use smaller and safer EC keys, replacing 2048 bit RSA.
NID_X9_62_prime256v1 is roughly as secure as a 3072 bit RSA key, but way shorter.
Since we have to embed the key in the identity packet that is sent over UDP and
some stacks aren't happy with large UDP messages (notably: macos), I switched to
EC instead of to a longer RSA key.
This seems to be compatible with other clients even on older systems like Android 5.0.
I did stick with NID_X9_62_prime256v1 because stronger EC like NID_secp384r1 failed
the handshake (I didn't investigate why).
We now store the kind of key in the config, so we can know which kind of key we are loading.
Now that devices can potentially be connected via both network and bluetooth simultaneously we should prioritise connections over the highest performing link (probably wifi/network). To this end the
m_deviceLinks are now sorted based on priority with the fastest links first; this means that when Device::sendPacket is scheduling to send a packet, it should always use the fastest link first.
The device ID is sanitized to make it safe for D-Bus, so the device ID
stored in the certificate as the subject name also needs to be
sanitized before comparison.
We operate on a QSharedData object and thus can trivially make a copy. We generally don't use use const refs as return values in KDE APIs unless there is a compelling reason to do so
