GitLab

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Ahmad Samir authored Jun 05, 2022 and Alexander Lohnau committed Jun 05, 2022

E.g. when building KIO:
About to parse service type file "/usr/share/kservicetypes5/kcmodule.desktop"
....
...
Found property definition "X-DocPath" with type "QString"
Unknown property type for key "X-KDE-ParentApp" -> falling back to string
Unknown property type for key "X-KDE-Keywords" -> falling back to string

GIT_SILENT

This way the list items all have a consistent height, even when some
don't have a subtitle.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

We do this in other KCMs; let's do it here too.

In other KCMs, we use a one-shot timer to delay the time before the
message can appear, so that it doesn't flicker between visible and
hidden when the KCM first loads. Let's do that here too.

The size and positioning code need to be attached to the loader, not its
component item.

This way one can better debug, from where the KCM was loaded. For example
if one wants to know which KCMs were loaded from the kdesrc-build setup
and which KCMs were loaded from the system setup.

Otherwise, the second value ends up being undefined if the metadata does
not have a version set.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

The KCModuleProxy is parented into the widget hierarchy and thus deleted when the page is removed

Remove manual delete to avoid a double delete

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

We need to set the query explicitly, because we can not longer read it from the line edit directly.

See:
https://kde.org/info/security/advisory-20220131-1.txt
https://mail.kde.org/pipermail/kde-devel/2022-January/000943.html

Unlike KPluginSelector/KPluginWidget, the KPluginModel does not have the functionality to
display the config of a plugin. Meaning consumers will need to take care of implementing a `showConfiguration` like method.
For doing this we need the KPluginMetaData object of the config.

For example the KRunner KCM has the functionality to open a plugin's config by passing in the
plugin id to the args when creating the KCModule.

Using the kcm variable only works if we have loaded a KCM.

Co-authored-by: Nate Graham

This way consumers of the QML KPluginSelector do not
need to care about creating the proxy model.

By having it in a static lib, we do not need to export the class
or run into issues with multiple definitions of the class.

Task tracked at:
teams/frameworks-devs/kf6-workboard#2

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

For the KWin KCMs we need the full metadata, because we read the
plugin keyword.

Without the X-KDE-ConfigModule key, plugins used to create a symlink
in the kservices5 folder to their metadata, which then goes through the
legacy code path we would read all the metadata.
This includes the plugin keyword.

When consumers would this key, but have an old KWin version which
used the KPluginSelector class and a kcmutils version which reads X-KDE-ConfigModule, but does not
include this bugfix, the plugin keyword will be empty and thus the config
files can not be located.

This makes it hard to fix the loading on kcmutils < 5.91, but keeping the
code working with KWin < 5.24.

To test this, you should check out KWin 5.23 and kcmutils master.
Fox example https://github.com/nclarius/tile-gaps/ will then fail
to load it's config. With this change included, it should load properly.

BUG: 444378