K_EXPORT_PLUGIN

[Aaron J. Seigo]

On Monday, February 25, 2013 17:38:09 Aaron J. Seigo wrote:
> can somene point me in a useful direction? thanks.

let me try again, this time with more details on what i'm actually looking 
for[1].

right now in libplasma2 we have definitions like this:

#define K_EXPORT_PLASMA_APPLETSCRIPTENGINE(libname, classname) \
K_PLUGIN_FACTORY(factory, registerPlugin<classname>();) \
K_EXPORT_PLUGIN(factory("plasma_appletscriptengine_" #libname)) \
K_EXPORT_PLUGIN_VERSION(PLASMA_VERSION)

then in a plugin:

K_EXPORT_PLASMA_APPLETSCRIPTENGINE(declarativeappletscript, 
DeclarativeAppletScript)

and then to load it:

KService::Ptr service = .. something that gets us a service ... ;
ScriptEngine *engine  = service->createInstance<Plasma::AppletScript>(parent, 
args, &error);

that was then ... this is now. i'd like to do this:

Q_DECLARE_INTERFACE(Plasma::AppletScript, "org.kde.plasma.AppletScript")
#define PLASMA_APPLETSCRIPT_PLUGIN Q_PLUGIN_METADATA(IID 
"org.kde.plasma.AppletScript")

and then in the plugin:

 class DeclarativeAppletScript : public Plasma::AppletScript
 {
     Q_OBJECT
     PLASMA_APPLETSCRIPT_PLUGIN

so far so great, excep that service->createInstance no longer works.

if I replace this with:

KPluginLoader loader(*service);
ScriptEgnine *engine = qobject_cast<ScriptEngine *>(loader.instance());

it loads the plugin ... but now we have a few problems:

0) QPluginLoader::instance() returns the same instance of the plugin. i need 
*new* instances every time, which means i need a factory and not the plugin 
itself .. which means i'm back to needing something like K_PLUGIN_FACTORY

1) this is wildly not source compatible for our plugins. even if we ignore the 
changing of the macros, the constructors now change too -> no parent, no args, 
etc.

2)  we still need things like the plugin version checks which we do with 
K_EXPORT_PLUGIN_VERSION(PLASMA_VERSION). do we now need to add this to each 
plugin with a new #define (or similar) or is the idea to move to some other 
facility provided by Qt's plugin loading system? should this be rolled into 
KPluginLoader and/or KService's loading rather than be a separate call 
(KPluginLoader::pluginVersion, and comparing that to a built-in version #)?

so, yes, from a plugin WRITER's perspective, this change is all obvious and 
straightforward. from the perspective of someone creating new plugin TYPES, 
porting away from the K_PLUGIN_FACTORY thing is anything but obvious.

and that's what i'd like some input on from those involved with this set of 
changes, e.g. dfaure.


[1] yes, i too have found the plugnadpaint example in the qt5 sources! ;)

-- 
Aaron J. Seigo
-------------- 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/20130226/789d8410/attachment.sig>