RFC: a replacement for KPluginLoader

[David Faure]

On Saturday 04 May 2013 18:04:13 Aaron J. Seigo wrote:
> 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.

Great, then let's do that.

> The *only* reason I'm touching this item is because the class is marked as
> deprecated. 

Which class do you see as "marked as deprecated"? KPluginFactory is not 
deprecated, only K_EXPORT_PLUGIN is (because Qt forced it out).
KPluginLoader is not deprecated either.

And both of these classes are in the "kservice" framework, not in something 
like kde4support.

> That  means it likely will not be in minimal builds (e.g. ones
> targeting small devices) and will one day disappear on us.

K_EXPORT_PLUGIN, yes, but not the KPlugin* classes.

I think all this is a rather large misunderstanding.
KPluginLoader and KPluginFactory are not deprecated, exactly for the reason 
you found out: we have nothing better at the moment. So that's what we have, 
let's use that.

> I don't want a plasma specific solution. I also am not able to sit here with
> no solution.

Could you give this solution a try? Keep KPluginLoader and KPluginFactory,
and write a replacement macro for K_EXPORT_PLUGIN which creates a QObject with 
the metadata line (hmm, macro inside macro, will that work?). That's the bit 
that's missing, right? Exporting the factory as the "one object returned by 
the qt plugin framework"?

If this works, then it should be added to kpluginfactory.h -- no reason to 
make it plasma-specific, as we both agree upon.

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