KF6 meeting notes 2021-05-29

[Luigi Toscano]

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