As discussed in Matrix and BUG: 474121 this plugin is confusing (because
it doesn't actually take a photo, it just launches the camera on your
phone) and its use case can be covered by taking a photo and sharing it,
which only requires a couple extra clicks.
This sends generic multimedia keyboard events, since the implementation
using GlobalSystemMediaTransportControlsSessionManager had some problems:
the SessionsChanged event doesn't work on recent Windows versions,
plus many players don't implement this API (eg: VLC, Windows Media).
This is far less code and allows for an easier enforcing of standards, for
example the name of the log identifiers which were adjusted in a few cases.
Also clean up unused includes when noticed.
Those plugins re really simple and don't need any initialization logic.
With the using statement, we do not need to add a constructor and pass the parent/args to the baseclass
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.
* Moves the XML definitions of DBus interfaces and code generation from the different plugins
to kdeconnectinterfaces. Before each plugin had their own, some of them duplicated.
* Appends `// clazy:skip` to the generated interface files, so Clazy doesn't emit warnings
about them because they are missing the NOTIFY/CONSTANT keywords on Q_PROPERTIES.
* Makes kdeconnectinterfaces static on Qt5 as well (removes a difference with Qt6).
* Moves the generated files to a `generated` directory and updates the includes so they are
easily distinguished from other header files.
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.
By removing the postfix we consistently use, we get exactly the same string as before
However, all our pluginId logic is now done as part of the buildsystem.
Before, they were in the JSON metadata, the buildsystem and the string constructor parameter
KPluginFactory has the KPluginMetaData object in any case, do using it
doesn't create any overhead.
This way we catch missing methods/mismatching arguments at compile and
not at runtime.
This fixes some Qt6 regressions due to the removal of deprecated methods.
We do not need those methods to be marked as slots and the KCMUtils
classes like KPluginWidget also don't need it.
Meaning it just results in more moc code being generated.
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.
- Add dummy args param to QProcess::startDetached
- Remove logging category from inline snippet. This was removed due to
being unused in non-windows builds.
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.
