Create Task
Maniphest T13555

Create replacement for KPluginInfo::kcmServices
Open, Needs TriagePublic
Actions

Description

We want to get rid of KPluginInfo. Therefore we need an alternative to KPluginInfo::kcmServices. It is used for finding a plugin's config module. KPluginMetaData does not have an equivalent.

Internally it uses KServiceTypeTrader to look for plugins of type KCModule that have the target plugin as X-KDE-ParentComponents. This approach seems weird to me. It seems more natural to have the plugin define its config instead of the other way around

A solution that is used in KWin (https://invent.kde.org/plasma/kwin/-/merge_requests/306) is adding a new key X-KDE-ConfigModule to the plugin metadata that holds the id of the config module

Related Objects
Search...

davidre added a subscriber: davidre.Jan 22 2021, 2:10 PM

Just that is writen somewhere the final key used was: X-KDE-ConfigModule

nicolasfella updated the task description. (Show Details)Jan 22 2021, 2:12 PM
nicolasfella updated the task description. (Show Details)
ltoscano moved this task from Needs Input to Done on the KF6 board.May 22 2021, 2:44 PM
ltoscano added a subscriber: ltoscano.

(post KF6 meeting 2021-05-22): this specific ticket is done, the two use cases have been fixed.

alex added a subscriber: alex.Jun 26 2021, 3:18 PM

In the KSettings::Dialog class this is still used. I am working on getting rid of that class, at least in kcmutils.

I have ported the individual KCMultiDialogs usages inside of PIM to KPluginMetaData and all of the KCMs for each app are its own namespace.

Now there is the case where the Kontact plugins can have quite a few KCMs that are all in a specific namespace. Should I use a key like X-KDE-ConfigModuleNamespace for this? Listing the individual KCMs is IMHO a bit annoying and searching for those would be more expensive, both code and performance wise.

nicolasfella added a comment.Jun 26 2021, 4:31 PM

Sounds reasonable