Create Task
Maniphest T14733

Move away from using KAboutData in KCMs
Open, Needs TriagePublic
Actions

Description

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.

Related Objects

nicolasfella added a comment.Jul 20 2021, 10:10 PM

After some digging I learned that systemsettings can show an about dialog for KCMs. It's only exposed when using the icon view, which we are on the verge of getting rid of it anyway. The fact that nobody bothered to add it to the sidebar view is a hint about how useful it is

davidre added a subscriber: davidre.Jul 21 2021, 6:46 AM
In T14733#260695, @nicolasfella wrote:

After some digging I learned that systemsettings can show an about dialog for KCMs. It's only exposed when using the icon view, which we are on the verge of getting rid of it anyway. The fact that nobody bothered to add it to the sidebar view is a hint about how useful it is

no hard to blocker for KPluginMetaData since https://api.kde.org/frameworks/kxmlgui/html/classKAboutPluginDialog.html exists

nicolasfella added a comment.Jul 21 2021, 12:42 PM

One thing KAboutData is used for is setting the translation domain for QML KCMs. T13056 touches this topic

alex moved this task from Backlog to In Progress on the KF6 board.Oct 31 2021, 7:14 PM
nicolasfella added a comment.Dec 12 2021, 2:14 PM

For QML KCMs this is all implemented on the frameworks side.

For KCModule there is one internal usage left: It uses the KAboutData's componentName for some KAuth stuff: https://invent.kde.org/frameworks/kconfigwidgets/-/blob/master/src/kcmodule.cpp#L128

Options here would be to use the same KPluginMetaData-via-ctor approach as for the QML KCMs or passing that id via a setter

alex added a subscriber: alex.Dec 12 2021, 7:09 PM

For KCModule there is one internal usage left: It uses the KAboutData's componentName for some KAuth stuff:

Couldn't we use the same approach as in https://invent.kde.org/frameworks/kdeclarative/-/blob/master/src/quickaddons/configmodule.cpp#L76?

alex added a comment.Dec 12 2021, 7:10 PM

Currently for a QML-based KCM there are three sources of metadata:

  • The KPackage's desktop/json metadata

That bit is covered by T14983 and done for pretty much all plasma KCMs.

alex added a comment.Feb 17 2023, 7:34 PM

@nicolasfella I have the import of those classes in kcmutils in progress and will make a MR this week. There I already dropped this API.

nicolasfella added a comment.Feb 17 2023, 7:37 PM
In T14733#267634, @nicolasfella wrote:

For QML KCMs this is all implemented on the frameworks side.

For KCModule there is one internal usage left: It uses the KAboutData's componentName for some KAuth stuff: https://invent.kde.org/frameworks/kconfigwidgets/-/blob/master/src/kcmodule.cpp#L128

Options here would be to use the same KPluginMetaData-via-ctor approach as for the QML KCMs or passing that id via a setter

KQuickAddons::configModule has setAuthActionName, KCModule could have the same

alex added a comment.Feb 17 2023, 7:47 PM

KQuickAddons::configModule has setAuthActionName,

That is what I added on my WIP branch to the base class, https://invent.kde.org/frameworks/kcmutils/-/commits/work/alex/kcm_import_and_refactor

Options here would be to use the same KPluginMetaData-via-ctor approach as for the QML KCMs or passing that id via a setter

I think passing in the ID via a setter would be cleaner, because the full ID has to be typed out for providing the kauth action. Having it once explicitly stated and once derived from some internal string concatenation with the pluginId seems weird.

nicolasfella added a comment.Feb 17 2023, 7:49 PM

I think passing in the ID via a setter would be cleaner, because the full ID has to be typed out for providing the kauth action. Having it once explicitly stated and once derived from some internal string concatenation with the pluginId seems weird.

Agreed, we should use a setter for the ID and remove the implicit thing

alex claimed this task.Feb 18 2023, 1:58 PM
alex moved this task from In Progress to Done on the KF6 board.Apr 9 2023, 6:00 PM