KParts can have plugins associated with them. This is pretty much only used for Konqueror where the various web parts have all kinds of plugins/extensions associated with them. While most of the logic lives in KParts it leaks into KPluginInfo (https://invent.kde.org/frameworks/kservice/-/blob/master/src/services/kplugininfo.h#L212, unused) and KPluginSelector (https://invent.kde.org/frameworks/kcmutils/-/blob/master/src/kpluginselector.h#L92, only used in Konqueror).
For the future I have one radical and some less radical alternative proposals:
Radical proposal: Declare the concept of KPart plugins dead and turn the existing ones into Konqueror plugins. Given that KHTMLPart and webkitpart are on the way out we are converging on having a single browser part. That would leave webenginepart and dolphinpart as the sole consumers of these plugins.
Less radical proposals:
If we decide we still want to stick to the concept of KPart plugins then there is some cleanup in order.
- https://invent.kde.org/frameworks/kservice/-/blob/master/src/services/kplugininfo.h#L212 is unused and should be deprecated and removed (which KPluginInfo should be anyway)
- Loading the plugins should use the standard mechanisms (KPluginLoader + KPluginMetaData). That implied embedding the metadata into the plugins and moving the install location to something like $PLUGINDIR/kpartplugins/$COMPONENTNAME. This needs some thought about the adjacent .rc files.
- Drop the explicit support in KPluginSelector (https://invent.kde.org/frameworks/kcmutils/-/blob/master/src/kpluginselector.h#L92) in favor of generic support, enabled by the above point
- Drop the plugins for khtml and webkit parts