KPackage: Port away from using pluginId as package type
Open, Needs TriagePublic

Description

This mixes the concept of ServiceTypes and pluginIds. Especially if we are trying to get rid of explicitly defining the plugin id and using the filename instead.

An alternative could be to define an explicit key, like KPackageFormat which has a simple string as value.

I am doing some simplification of the plugin loading code, which will make it easy to extend it by adding this extra key.

alex created this task.Jun 8 2021, 10:21 AM
mart added a comment.Jun 9 2021, 8:21 AM

I agree with the proposal.
Since this would correspond to the PackageStructure to load, it could even be called KPackageStructure

alex added a comment.Jun 9 2021, 8:24 AM

Could it make sense to rename the ServiceTypes field in the metadata too? This would not affect the functionality, but would ensure that KPackage terminology is used instead of the KServiceTypeTrader one, which does not relect reality since KF5.0.

alex added a comment.Aug 10 2021, 12:16 PM

As we discussed a key called IsContainmentAction should be used to identify applets which should be loaded as a containment. They still use the same package structure as regular applets.

@mart I am wondering if we even need to define the KPackageStructure key for the packages if we install them using cmake. For installing the cmake macros take care of it and for querying we use the filesystem.

mart added a comment.Aug 17 2021, 6:25 PM

Not only cmake is used, knewstuff also installs them downloaded from the store

mart added a comment.Aug 17 2021, 6:32 PM

So would always keep the kpackagestructure key in installed metadata for completeness

alex moved this task from Backlog to Done on the KF6 board.Feb 18 2023, 7:13 PM