Remove X-KDE-PluginKeyword and keyword parameter in KPluginFactory::registerPlugin
Open, Needs TriagePublic

Description

X-KDE-PluginKeyword allows to instantiate multiple classes from a single plugin binary. It is very rarely used, mostly for having multiple KCMs sharing a single plugin binary.

This forces us to go through KServiceTypeTrader/desktop file based loading for loading KCMs. If we could assume that there is only one KCM per plugin binary we can simplify this and just use KCoreAddons API to load KCMs.

I ported some trivial/unneeded usages. Non-trivial usages left are in:

Those need to be ported to have a plugin per KCM, which is not hard but a bit of boilerplate.

There is also some unorthodox usage in KWin. There a generic KCM binary is loaded for some scripts/effects that then uses the plugin keyword to load the relevant UI. Those need a bit of thinking. We could for example pass the relevant parameter in the args when instantiating the plugin

nicolasfella updated the task description. (Show Details)Jul 23 2021, 4:55 PM
alex added a subscriber: alex.Jul 23 2021, 8:50 PM

@nicolasfella T14730 is for cleaning up these properties from the data files & public API, which includes this property. And for the KCM loading there is T14517.I would say that this already covers this task :)

alex added a comment.Jul 26 2021, 5:16 PM

Notes from KF6 weekly:

The keyword stuff is not really needed and should be deprecated. Multiple plugins can be loaded without it being involved, if the classes are different. That is in most of the current usages the case. The KCMs in kinfocenter should be ported to KPluginMetaData and will not need the keyword stuff afterwards. See https://phabricator.kde.org/T14517.
The X-KDE-KCM-Args property might help with the KWin usages. But it needs to be read from the plugin which has the config modules, not the config module itself.

alex renamed this task from Remove X-KDE-PluginKeyword to Remove X-KDE-PluginKeyword and keyword parameter in KPluginFactory::registerPlugin.Jul 27 2021, 3:59 PM
alex moved this task from Backlog to In Progress on the KF6 board.Aug 1 2021, 5:45 AM
alex added a subscriber: zzag.Aug 8 2021, 2:42 PM

For the KCM loading of the effectsin KWin the X-KDE-KCM-Args property should be suitable.

The themeFinder stuff is more difficult. Maybe it should be it's own class. Having a QObject, using QMetaObject::invokeMethod and reading a property using a string seems a bit hacky. @zzag smaragd seems to make use of that. Is this still maintained?

And do we need to keep source code compatibility for the KWin APIs?

zzag added a comment.Aug 10 2021, 3:01 PM

What's smaragd?

zzag added a comment.Aug 10 2021, 3:01 PM

And do we need to keep source code compatibility for the KWin APIs?

Generally speaking, no. But we try not to break it needlessly.

alex added a comment.EditedAug 10 2021, 3:02 PM

What's smaragd?

https://invent.kde.org/plasma/smaragd

Generally speaking, no. But we try not to break it needlessly.

Yep, of course I will try to keep the changes at a minimum.

alex added a comment.EditedAug 23 2021, 7:38 PM

https://invent.kde.org/plasma/kdecoration/-/merge_requests/11
https://invent.kde.org/plasma/kwin/-/merge_requests/1289

That should take care of all the KWin bits. The KInfoCenter usages have open MRs.

alex claimed this task.Oct 10 2021, 10:53 AM

Konqueror is taken care of with:

https://invent.kde.org/network/konqueror/-/merge_requests/92

The KWin and KInfoCenter changes already landed.

alex added a comment.Oct 24 2021, 7:56 AM

KMyMoney uses the keyword stuff too, though not in combination with the X-KDE-PluginKeyword, but rather json based plugins.

It will need further investigation how one can port that.

alex added a comment.Oct 29 2021, 5:19 AM

See https://invent.kde.org/office/kmymoney/-/merge_requests/124, the plugin keywords were a workaround for the internal factory not being a QObject.

Now the overloads can be deprecated in kcoreaddons.

alex moved this task from In Progress to Done on the KF6 board.Feb 17 2023, 1:57 PM