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
KDNSSD only works with Avahi (so, only on Linux) while mdns.h is a
header-only library [1] that implements mdns from scratch and should
work on all platforms.
[1] https://github.com/mjansson/mdns
We can always provide a function rather than a value.
This is what we do in most places already and is consistent with the
rest of KDE.
This gets compiled to the same code.
```cpp
explicit QLoggingCategoryMacroHolder(const QLoggingCategory &cat)
{
if (IsOutputEnabled)
init(cat);
}
explicit QLoggingCategoryMacroHolder(QMessageLogger::CategoryFunction catfunc)
{
if (IsOutputEnabled)
init(catfunc());
}
```
By commenting out the parameter name, we get compile-time checks
Also, we can omit them for slots and Qt will not forward the parameters.
In case we had TODOs next to the code, I kept the Q_UNUSED statements
for now.
Overriding and defaulting them in the header doesn't make sense
For the dbus interfaces, we don't have any reasources to clean up or memory to be released. Meaning we can drop those lines too
- Using QLatin1String when concatinating strings is faster, because they
are more lightweight. For the resulting string, we need to allocate
new memory anyway
- Use QLatin1String overloads where they are provided by Qt APIs
- Just use const char* for log messages, the quoting of QStrings is not
needed
- Make sure to reuse string results when possible
- We do not need the return type. If a plugin declares it can handle the
packet it should do so. We don't have any fallback logic in place and
the packet types are namespaced with the plugin IDs anyway.
- Provide a default implementation with a warning, not all plugins need
to overwrite this
The rationale is explained in https://planet.kde.org/friedrich-kossebau-2023-06-28-include-also-moc-files-of-headers/
In case of KDEConnect, it impressively speeds up compilation. Before it
took 390 seconds on a clean build and with this change it took 330 seconds.
This is due to the mocs_compilation having to include the header files
and thus all their headers. Due to the lots of small plugins we have,
this means that the same headers must be compiled plenty of times.
When we include the moc files directly in the C++ file, they are already
available.
