DataEngine & KPluginFactory

[Sebastian Kügler]

Hi David,

On Tuesday, June 25, 2013 12:39:08 David Faure wrote:
> > Ignoring our home-made deprecation warning, it seems KPlugin* is still
> > working.
> 
> Clearly I did too good a job with the hack in the macro. It works so people 
> want to keep that hack
> 
> The problem is that it again creates a system that is incompatible with
> Qt's  builtin plugin loading.

I'm not quite sure why that's a problem, if Qt's plugin loading mechanism 
can't do what we want, we have two options:

(a) Use a different one (e.g. KPlugin*), would incur increased maintainance 
    overhead, more and different code paths
(b) Improve Qt's plugin mechanism (perhaps based on the solution we found for 
    (a))

Let's assume for now that a system closer to Qt's is what we want, however.

> With this hack, there's no .json file that Qt
> wants to use in order to find which plugins to load. So we'll need to keep
> our own description mechanism (.desktop files) and our own selection
> mechanism (ksycoca). I was hoping we could use Qt for all this, with .json
> files for the description (including all the stuff you find in KPluginInfo)
> and, json for querying capabilities (well, the querying is a bit more
> limited in Qt, better use subdirs for plugins of the same type, since
> there's no trader-query- syntax, one has to check each plugin in the
> subdir).
> 
> So in the long run, I don't like keeping the current hack. We could of
> course  "keep it for now" but porting to something else after a first
> release will be even more trouble (with the need for compat etc.).
> 
> My idea was: forget the KPlugin* stuff for a minute, look at a standard Qt5 
> pure-Qt plugin, and from there try to elaborate a solution for the plugin
> object being a factory rather than a single object.
> Once that's done, try to make it as close to KPluginFactory as possible
> While doing that, you'll notice that there's no need for any K_EXPORT_
> macro. If you don't feel like doing this, I'll have to (but time is an
> issue...), because I think we should at least evaluate the option of doing
> something a lot more compatible with Qt5.

I agree. I don't exactly feel like I'm up to it, but maybe that's my challenge 
for a learning experience. I'll work a bit more on this, be sure to see me 
come back with more questions.

My thinking is: get a kde-specific solution going, then look if it's upstream 
material. If so, work on merge, if not: bad luck. :)

I'll have to let the rest of your email sink in a bit, and then play around 
with it.

Thanks so far,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9