What KPluginMetaData misses though is the ability to query the enabled state.

We have an EnabledByDefault json key & a getter for it, however it misses the KConfig integration like KPluginInfo does.

I have a local draft to add a templated method, which then reads the pluginId()+"Enabled" value from the given object and uses the EnabledByDefault as default.

template<typename T>
bool isEnabled(const T &config)
{
return config.readEntry(pluginId() + QLatin1String("Enabled"), isEnabledByDefault());
}

Because KCoreAddons is tier 1, we can not use KConfig directly. Because of that I don't think we should create any stateful logic, but only a simple read method.

The writing is currently done in KPluginSelector (or the new KPluginWidget), because of that I don't see the need to provide a setter/write method in KPluginMetaData.

Any thoughts?

Instead of a function template, how viable would it be to use QSettings? for example Sonnet uses QSettings since it's in a higher tier and can't use KConfig.

About the writing/saving, is there any use cases for it? i.e. when porting, would it be an issue for users of KPluginInfo? if there is no use-case, then we can always it add it when there is a use-case.

And looking at the KPluginMetaData API, most of its methods are getters and const, which sort of makes sense, if querying the available plugins, but not changing anything about them.

Instead of a function template, how viable would it be to use QSettings?

In all cases I know of the consumer already has a KConfigGroup of KSharedConfig object. Using QSettings would force us to reparse the configuration or force consumers to manually create the QSettings object & access the relevant group.

for example Sonnet uses QSettings since it's in a higher tier and can't use KConfig.

But there is a significant difference: The settings for Sonnet are read and written internally, KPluginMetaData would provide them for external use.

I see; a round-about way would be to get the file name from kconfig and pass it to KPluginMetaData which would then create a QSettings object and read the entry; but that is a bit more hassle.

About the writing/saving, is there any use cases for it? i.e. when porting, would it be an issue for users of KPluginInfo?

Since deprecating KPluginInfo would as a consequence remove this feature, I wanted to substantiate, why I don't think it is worth creating a replacement for it in KPluginMetaData.

All the frameworks parts have KPluginMetaData replacements.

KPluginInfo was deprecated with https://invent.kde.org/frameworks/kservice/-/merge_requests/67

https://invent.kde.org/frameworks/kservice/-/merge_requests/110