RFC: a replacement for KPluginLoader

[David Faure]

On Monday 29 April 2013 22:19:58 Aaron J. Seigo wrote:
> hi..
> 
> currently libplasma uses the KDE plugin loading mechanisms *extensively*.
> they have also been marked as deprecated. the goal for frameworks, as i
> undestand it, is to move to a QPluginLoader.
> 
> QPluginLoader has a major limitation, however: it only returns a single
> instance of a class from the loaded library. one. ever. only. :)
>
> obviously, applications such as Plasma Desktop need to load the same plugin
> many times, as needed. the solution is obvious: create a factory class that
> returns new instances of the class(es) inside of the library.

Yep.
 
> during our weekly plasma-workspaces meeting this topic came up and i
> suggested an approach (which I've also discussed with Thiago in passing)
> which i plan to implement at least for plasma- workspace as a short-term
> solution to get away from the KDE plugin loading.
> 
> i will introduce a new macro (so that it remains source compatible, at least
> for libplasma) that creates a QObject subclass which itself provides a
> factory method to create new instances of the class(es) in the library.
> 
> i would also like to fold in version compatibility checks. the resulting API
> of the generated object will look something like:
> 
> template<class T> T *create(QObject *parent = 0) const;
> bool isVersionCompatible(quint32 minVersion, quint32 maxVersion);

That's the API for the application, the plugin itself will only know "I have 
been created with version number 3", right?

This makes sense to me (more than tying to Qt or "kdelibs" versions, which are 
often unrelated to changes in the ABI used by plugins).

> create will be used similarly to how it KPluginLoader is now: create<Foo>()
> 
> the QVariantList parameter will be removed as it seems to serve little real
> world purpose with how we design APIs now.

Sounds good.

About KPluginFactory: registerPlugin is always used, it's the only way to 
declare your plugin class to the macro. The reason for that strange api 
though, was to be able to have multiple classes in one plugin, identified by a 
keyword (= fixed string). This is mostly used by KCM modules, so that multiple 
pages (instanciatable separately) can be provided by a single plugin file.

I wonder if this fits with the "json metadata" Qt5 idea, but maybe it does
(the metadata could say "keywords=cookies,ssl,bookmarks")

So yeah, maybe we want to keep using KPluginFactory instead of writing yet 
another plugin framework doing pretty much the same. The version check can be 
added to KPluginFactory, to basically replace the KDE_VERSION_STRING based 
one.

And yes, automatic catalog loading is commented out, but if we ever want to 
re-enable it, better do that in a central location than in every application 
that had to build their own framework on top of QPluginLoader.
Auto catalog loading in Qt itself is a rather longer term TODO...

Overall, I don't have an extremely strong opinion: it's the usual tradeoff 
between "writing something new with less features, so simpler to use" and 
"keeping the existing solution, for maximum source compatibility i.e. reduced 
porting effort".

When you talked to Thiago, was there any talk about adding a macro like the 
one you mention, to Qt itself? After all the KDE community can't be the only 
one in need of plugins that can create multiple objects. If you think of 
something that could actually go to Qt, then that would be my preferred 
solution.

In summary:   Qt solution > KPluginFactory > Plasma-specific solution

Kévin wrote:
> kpluginfactory.h includes kexportplugin.h but AFAICT it never uses anything 
> from there.

Correct, this was just for convenience since anyone using kpluginfactory had 
to export it too. I tested locally what happens when removing the include. It 
needs to be re-added to all plugins, but it shows that the two things are 
independent indeed. I guess I shouldn't commit this, though. Even if we 
deprecate K_EXPORT_PLUGIN, better keep including the header, so that users of 
the macro get a clearer error message than when using K_EXPORT_PLUGIN and that 
macro isn't defined:
error: expected constructor, destructor, or type conversion before ‘(’ token

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5