Hi all, no "needs input" tasks have been discussed this time, the focus has been on several tasks all related somehow to KCMs and plugin loading.
I think this was not really a problem. While there are still "needs input" tasks around, it is more and more likely to end up discussing other tasks now that the work is ongoing and several doubts have been clarified. While reading about the following point, you may notice that they have been already discussed. So some of the "conclusions" may not be really new. And now, the tasks. - https://phabricator.kde.org/T14517 "Consider creating replacement for desktop file KCM loading & querying" Discussion over the 3 options, also in connection with the future changes of the way KCMs are and will be handled, see the previous meetings. Leaning toward solution KPluginLoader + some API in (KCMutils?) With KCMs separated by namespace (per-type directory), not having caching wouldn't be a problem. That would mean replacing X-KDE-Parent-App with folders hierarchies. - https://phabricator.kde.org/T14314 (Create helper function for plugin loading) Discussion and clarification over the need for KExpected - it is needed to know why the operation failed -> it seems it can be removed through a custom struct with the information about the error. Follow up on the review. The discussion touched the handling of the plugin versioning ( https://phabricator.kde.org/T14302 was mentioned) Most cases are handled by Qt internally. Other programs namespace the plugins by plugin version (for example KDevelop, which increases the version when the plugin API changes) -> Summary: We have 3 different ways of handling plugin version, we can remove the compiled-in version (from before the new plugin). "Namespaces" and "plugin metadata" have a use case. Handling the right version is an application problem. There was a question on whether KPluginFactory should stay. -> Yes, there are some usecases where it is needed to load multiple instances of the same plugin, which is not covered by the Qt system (for example in KDEConnect). - https://phabricator.kde.org/T14303 (KPluginLoader: move static methods to KPluginMetaData) Note about this change increasing the porting time as it introduces a relatively big API change - but but we have seen worse! - https://phabricator.kde.org/T14499 (KPluginLoader: Use filename when searching for plugin by id) Question on whether an use case which allow for multiple results exist. It would be strange indeed (it may happen in case of copy-paste or mixed build/stable environment) PS. a small service announcement: I won't be around next Saturday (5th), so please find another volunteer for the notes. Ciao -- Luigi