- 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.
This is not needed, because only a symbol to create the KPluginFactory
instance must be exported. The KPluginFactory macros or rather the underlying
Q_PLUGIN_METADATA macro already take care of that.
In other plugin code of KDE, we also do not export classes.
The size of the generated plugin files is nearly identical, but removing
the macros avoids confusion for developers.
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.
The one derived from the filename is identical. Deriving it from the filename is the preferred approach.
In KF6, log messages are printed out if the Id is needlessly specified.
A mismatching Id vs basename would print out a warning.
The plugin version doesn't matter, because all plugins are shipped as
part of kdeconnect and not separately.
The website was also set inconsistently, some pointed to a custom blog,
the KDE homepage or a broken link. If we want to make announcements more
visible, we should have a link in a more central place.
The moc process already rebuilds the plugin when the JSON file changes, consequently the additional parameter is not needed.
Task: https://phabricator.kde.org/T14649
## Summary
This patch adds an interface to return only a specified window of messages, making loading the conversations history smooth, fast, and enjoyable.
The current implementation of the conversation interface loads all messages every time the conversation is requested. This is might be painfully slow to load in case the conversation is large or if there are a lot of MMS/RCS messages in the conversation (since those are wildly slower to load than SMS)
Requires https://invent.kde.org/kde/kdeconnect-android/merge_requests/122 to enable Android functionality
## Test Plan
- With new Android app and old Desktop app:
- The Android app will notice the missing fields and query for all messages as before.
- With old Android app and new Desktop app:
- The desktop will send fields for the new interface which will not be read and all messages will be returned.
- With new Android app and new Desktop app:
- The new interface is used and returns only a certain number of messages at a time.
We don't have a custom destructor and the copy ctor/assignment operator don't do anything special, so the default one will do the right thing.
This is in accordance with the rule of zero (https://cpppatterns.com/patterns/rule-of-zero.html)
While mostly theoretical it makes for a more expressive API since it communicates that it is a list instead of a single value. It also allows to get rid of some conversion code.
This is also preparation work for potentially using the custom type capabilities that QtDBus offers.
