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
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.
This makes it easier to read, because we do not have to handle a list of
files that get added to the targets. In other KDE projects, we also
prefer the target centric approach.
In case one wants to reuse the same category in multiple places, it
would be best to create a small static lib. But for now, this is not
needed.
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.
