- 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
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.
Change some optional dependencies from being optional to being mandatory
or being mandatory but behind on-by-default cmake flags. Eg: instead of
only compiling Wayland support if we find the appropriate libraries, we
always require the libraries unless the user specifies WITH_WAYLAND=OFF.
Optional libraries are hard to discover by packagers (since they don't
see an error once we add them) and create lots of possible build flavors
with a different features that can confuse users.
In theory we support Qt 5.6 (because of SailfishOS) but in practice we are not checking that in the CI so probably we broke the compatibility long ago. Also, I don't think anyone is using this code in SailfishOS, so we can greatly simplify the code by requiring Qt 5.15 or later.
Instead of always doing so on MacOS, do it only when we get a
DatagramTooLargeError. On MacOS, the size is limited only for
broadcast but not for unicast.
Since sockets are buffered `QIODevices` we can use `canReadLine()` to check
if we have a full line, instead of using a custom `SocketLineReader` class
(and the copy-pasted `DeviceLineReader` in the Bluetooth backend).
We can also loop through all the lines instead of queuing calls to `dataReceived`.
And we don't need transactions.
argument
Previously the BluetoothDeviceLink::certificate() method was returning a
value initialized object which I believe default initializes the object.
However, Clang throws a build error at this because QSslCertificate has
explicit constructors. This change uses one of those constructors and
uses value intialization to default construct/initialize the argument
for it. It fixes the build and hopefully doesn't break anything since
this is a TODO anyways!
BUG: 469428
Signed-off-by: Ali Abdel-Qader <abdelqaderali@protonmail.com>
This whole code was no-op: it enumerates network interfaces, enumerates
its IP addresses, but does not change the address of broadcast UDP
packet, sending it only via default route/interface.
Bind the socket to IP addresses of the interfaces to fix the issue.
BUG: 459171
This is the proper way to communicate progress.
It has Plasma show the file name in case of single files
and "n of m files" as before for multiple files.
On FreeBSD 12 or later, a new routing strategy is introduced, which
prevents broadcast using 255.255.255.255.
Thus, we need to explicitly send the broadcast to each network
interfaces.
Here the commit can simply reuse the code for Windows.
Ref: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252596
Detect the MTU on macOS and FreeBSD (which share the network parts of FreeBSD) and adaptively remove the outgoing and incoming capabilities.
The incoming capabilities are usually shorter, fit the size and help initialize the plugin list on the peer. This should fix an empty plugin list when the identity packet is sent by the macOS app.
If the MTU is still too short, both the capabilities need to be removed, which is not likely to happen.
Consider the following scenario:
1. We send a UDP broadcast
2. We receive a reply from 192.168.0.1 with device ID "foo"
3. We connect to 192.168.0.1, and find that the device's certificate
is actually for a different ID "bar". This could be because the
packet did not actually originate from 192.168.0.1, or this host is
malicious / malfunctioning.
4. We remember that device ID "foo" has certificate with common name "bar".
5. When we finally attempt to connect to the real device ID "foo", we
reject their certificate (common name "foo"). We can now never
successfully connect to "foo".
On some network (mis-)configurations, this completely prevents
kdeconnectd from connecting to any peers, because a reply which is
seen as originating from the local interface address will cause
kdeconnectd to immediately connect to itself and remember its own
certificate.
Address this by using the certificate display name of the peer, which
will match the real device ID.
The key is a sha256 of both devices' certificates. Both should generate the
same key, so hey user can check they are pairing against the right device.
Thanks Matthias Gerstner <mgerstner@suse.de> for reporting this.
