The Add command dialog currently does not set a preferredWidth, which
seems to cause repeated binding loops and a lot of log spam until the
dialog is actually put on screen.
This change sets the preferredWidth to 20*gridUnit, which seems to be
the typical size used in small dialogs and is about the size that the
dialog has without a width explicitly set.
While the HIG is not quite clear on this, PlaceholderMessages throughout
KDE applications and kcms tend to have sentence capitalization in their
title and include a verb (e.g. "Playlist is empty", "No game controllers
found"). The runcommand plugin breaks with this; it uses title
capitalization and does not include a verb: "No Commands".
This change modifies the title to read "No commands configured".
The ListView displaying the configured actions currently directly uses a
label that is made multi-line by including a newline. As a consequence,
eliding the text does not work properly and there is a visual clash with
the included action button. It also means that there is a rather
pointlessly translatable string that is just there for UI logic.
This change modifies the delegate to use a ColumnLayout instead, which
enables correct eliding of the labels and more cleanly separates layout
and content concerns.
The HIG recommend that buttons with an action label that require further
user input end in an ellipsis, and that dialog buttons should clearly
indicate what they do. Button labels typically do not match the given
exceptions that license sentence case. Currently, the main "Add command"
button in the configuration button does not end in an ellipsis even
though it opens a dialog, is sentence case, and the dialog has a "Save"
rather than the customary "Add" that is used for these kinds of actions,
in particular in kcms. The dialog title is also not translatable.
This change adds the ellipsis, converts the button to title case, makes
the dialog title translatable, and adds an "Add" button as an action to
the dialog.
The "Add Command" dialog in the settings for the Run Command plugin
looks rather broken at the moment, as the size is not explicitly set and
the default value ends up much smaller than the contents. It uses
QQC2.Dialog, even though the plugin makes heavy use of Kirigami. Using
Kirigami.dialog here would solve the sizing issue, and generally lead to
a more consistent interface.
This change makes the plugin use Kirigami.Dialog instead of QQC2.
BUG: 487438
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.
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.
- 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.
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.
