DataEngine & KPluginFactory

[Sebastian Kügler]

Hi,

On Tuesday, June 25, 2013 15:04:52 Sebastian Kügler wrote:
> I'll have to let the rest of your email sink in a bit, and then play around 
> with it.

I think I've roughly figured it out, see attached patch.

It registers KPluginFactory as Q_INTERFACE and provides a macro that writes 
out a simple KPluginFactory that gets included in the header, contains the 
Q_PLUGIN_METADATA and is picked up by moc and used to load the plugin (it will 
provide the q_plugin_instance call and our code from the macro.

The porting involved to make plugins work is:
- remove K_EXPORT_PLUGIN macro from plugin cpp file
- add K_PLUGIN_HEADER(FooFactory, Foo) to a header of the plugin 

An instance of Foo will be returned by the pluginfactory, The first argument 
(name of the resulting Factory class) can be chose arbitrary. We keep all the 
templated functions in place, so the change is mostly internal. We do need to 
install and #include <kpluginfactory.h>.

With that change (kpluginfactory.h diff + macro change in plugin), I can 
successfully load and run plasma-shell. So it appears I didn't break too many 
things. Also, make test in kdelibs seems to mostly work. I'm getting on fail 
in klibraryloader test, which I'll have to investigate (retest on another 
machine, for one).

Open questions:

- KPart and QWidget create* calls: In my current patch, these are simply 
  ignored.
  I'm getting away with one overridden function in our 
  macro-generated KPluginFactory subclass, it all seems to boil down to 

	virtual QObject *create(const char *iface, QWidget *parentWidget, \
									QObject *parent, const QVariantList &args, \
									const QString &keyword) \
        { \
            return new baseclass(parent, args); \
        } \

  as you can see, I'm using "baseclass" as return type. Is there a way to use 
  iface for the classname? If so, then this could be moved into an inline 
  method? 

- name of the macro: Suggestions?
  We'll need to move the macro into the header files anyway, so I don't think 
  we should reuse an existing name if we change the behavior under the hood, 
  leading to silent breakage? I'm still working on bringing 
  the macros closer together syntactically, but we'll want to change the name 
  simply to have the K_EXPORT_PLUGIN macro spit out a warning to use the new 
  macro (which has to be in the header file, not, as K_EXPORT_PLUGIN in the 
  cpp file).

- metadata: I've written a small program that reads a .desktop file and 
  outputs a .json file which can be included in the plugin. Right now, we 
  don't do anything with that data, but I think it would be useful to have as 
  it could remove reliance on ksyscoca in a few places. 
  Ideally, the conversion .desktop -> .json should be done during build-time, 
  so we can include updated translated strings without hassle. We don't want 
  to maintain overlapping data in .desktop and .json file. 

- Where can I find the definition of the cmake macro kde4_add_plugin() ? If I 
  create the plugin using add_library(...), cmake prepens lib to the plugin 
  name, which I don't want (the kde4_ macro doesn't do it, and KPluginLoader 
  won't find the binary either if we don't change all the .desktop files of 
  the plugins by prepending lib to the library name in there).

- versioning and kplugin_verification_data: I suppose those could be written 
  to the metadata of the plugin as well, this info should probably move into 
  the .desktop file.

One of the questions Aaron had in an email in February was how to make it 
clear and easy to implement one's own plugin types. On a lightweight level, 
this would require now changes at all: Just return whatever-instance-you-want 
and make sure it's the right kind of class in the receiver of 
KPluginFactory::create<...>(...). It could also be done by subclassing 
KPluginFactory and extending the K_PLUGIN_HEADER macro with some fancy 
constructors. I think this would make Plasma::PluginLoader pretty much 
unnecessary. Not sure if that would gain us much.

My code is in:

kdelibs[sebas/kplugins]
plasma-framework[sebas/plugins] (some test code, ported plugin)
kde-workspace[sebas/plugins] (ported timeengine)

So, comments most welcome. :)

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kpluginfactory-v1.diff
Type: text/x-patch
Size: 1299 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130701/461b7030/attachment.diff>