Re: [Soprano-devel] Soprano plugins on Windows

[Sebastian T. <tr...@kd...>]

On Wednesday 04 February 2009 08:04:47 Sebastian Trüg wrote:
> On Wednesday 04 February 2009 02:06:53 Greg Beauchesne wrote:
> > Sebastian Trüg wrote:
> > > yes, but they are no QObjects. I decided to keep the interface as small
> > > as possible. Mostly to allow plugin implementations to inherit from
> > > subclasses of QObject. Again this might not be the best solution.
> >
> > That's exactly the thing, though. The interfaces may not be QObjects,
> > but the base object exposed as part of Q_EXPORT_PLUGIN2() is a QObject
> > (e.g. Soprano::Redland::BackendPlugin), and if I'm not mistaken, that's
> > currently what you're dynamic_casting in PluginStub::plugin().
> >
> > > In any case it would be great if we could fix the PluginManager to work
> > > for Windows in 2.2.2 and then think about an updated plugin system for
> > > 2.3. Question is however, if it is worth the trouble or if we should
> > > simply create new parser/serializer plugins based on the old plugin
> > > system.
> >
> > Yeah, sorry, I didn't mean to start a discussion on redesigning the
> > whole plug-in system. One thing at a time.
> >
> > > well, I am declaring interfaces using Q_DECLARE_INTERFACE, even with a
> > > version string. Like I said: I cant really remember the actual reason
> > > for me to use the desktop files. I think I was not able to really make
> > > it work back then. Not sure.
> >
> > Yeah, looking at it now I see you do have it all set up and ready to go.
> >   It looks like you already have everything in place that you would
> > need, so I think qobject_cast<> should be no problem if you choose to
> > use it.
>
> As I said above, the base class to which I would have to cast is not a
> QObject. And the Qt documentation states that exactly that is necessary. To
> be sure I tried it and it does not work.

And now I know why: I use the class Soprano::Plugin as a base for all plugins. 
It provides a name and the isAvailable method. The plugin manager casts the 
QObject it gets from the QPLuginLoader to a Plugin object which cannot be done 
via qobject_cast since Plugin is no QObject and has no interface declaration. 
In the next step the Plugin instance is cast to Backend/Parser/Serializer 
which again cannot work since Plugin is no QObject.
So the solution could only be (if one was to keep the plugin system as is) to 
directly cast from Qobject to Backend/Parser/Serializer and skip the 
intermediate Plugin step.