RFC: a replacement for KPluginLoader

[Aaron J. Seigo]

On Saturday, May 4, 2013 17:06:21 David Faure wrote:
> On Monday 29 April 2013 22:19:58 Aaron J. Seigo wrote:
> > 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?

correct.
 
> 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
...
> I wonder if this fits with the "json metadata" Qt5 idea, but maybe it does
> (the metadata could say "keywords=cookies,ssl,bookmarks")

yes, that's what i was thinking as well.

> 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.

that'd be good ...

> 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

agreed

> 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".

If we keep the current solution thenwhy deprecate it? Simply keeping what is there would be the 
best thing from an app developer's POV.

The *only* reason I'm touching this item is because the class is marked as deprecated. That 
means it likely will not be in minimal builds (e.g. ones targeting small devices) and will one day 
disappear on us.

If it is deprecated then we need a replacement and that means something that uses 
QPluginLoader and that means something based on QObject.

So I don't see any room for tradeoff here at all. We either keep what we have now or we 
deprecate it and create a functional replacement.

> When you talked to Thiago, was there any talk about adding a macro like the
> one you mention, to Qt itself?

He does not want another class in qtbase for this. I'm not particularly sure how to achieve it 
without having at least a template class or a QObject interface defined somewhere somewhere 
given that QPluginLoader gives us back QObjects.

He was open to the idea of a macros, however.

He was not more specific as to what would be a workable solution.

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

I don't want a plasma specific solution. I also am not able to sit here with no solution. Every time I 
poke at either Qt or frameworks for these kinds of things, the feedback is vague and not 
particularly useful or encouraging. So that leaves me with the pragmatic thing: a solution that can 
be used now in Plasma which can demonstrate how it might be done and hopefully we can work 
from there to something that will be pick up by things lower in the stack.

-- 
Aaron J. Seigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130504/599cf48c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130504/599cf48c/attachment.sig>