Currently for a QML-based KCM there are three sources of metadata:
- The plugin's JSON metadata
- The KPackage's desktop/json metadata
- The KAboutData set in the plugin
It's not clear which information is taken from where leading to frequent confusions and duplication.
There is a trick to make the plugin and KPackage use the same desktop file, but the duplication with KAboutData still exists.
@sitter started work on removing the need for a KAboutData in https://invent.kde.org/frameworks/kdeclarative/-/merge_requests/48
It works by adding a new setter to KQuickAddons::ConfigModule to pass a KPluginMetaData that internally gets transformed into a KAboutData.
In https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/44 @kossebau added a way for plugins to access their KPluginMetaData, currently used for KParts and KRunner. I think it would make perfect sense to use the same approach here instead of a dedicated setter.
Assuming that there is no use case for having KAboutData that is not covered by KPluginMetaData (this still needs to be checked) we can then phase out the usage of KAboutData internally and in the public API.