K_PLUGIN_FACTORY changes explained

[David Faure]

On Friday 30 August 2013 17:36:20 Boudewijn Rempt wrote:
> I'm also not sure whether this still works with current e-c-m, but first we
> set the plugin_install_dir:
> 
> find_package(KF5 REQUIRED MODULE COMPONENTS CMake Compiler InstallDirs)
> set(kdelibs_SOURCE_DIR TRUE)
> # override the kf5 plugin installdir
> set(PLUGIN_INSTALL_DIR ${LIB_INSTALL_DIR}/calligra)

Ouch, why not set a different variable instead, say
  CALLIGRA_PLUGIN_INSTALL_DIR
?

Overriding values creates much surprise, for instance when copy/pasting a 
cmakelists.txt outside of calligra itself (e.g. for a playground module based 
on calligra). Suddenly your plugin's install dir changes, silently.

> Then we've got the KoJsonTrader class that tries to figure out in as generic
> as possible a way where that is -- maybe there's an easier way, but this
> seems to work. We're only interested in the type of the plugin, for now, so
> that's the only thing we check.
> 
> https://projects.kde.org/projects/calligra/repository/revisions/calligra-qt5
> -rempt/entry/libs/koplugin/KoJsonTrader.cpp

Ah, this is cool.
Well, the overall idea :)
The implementation would need some cleanup, but we could definitely use 
something like that in kf5 (possibly Qt itself).

* ::self() should use Q_GLOBAL_STATIC
* QCoreApplication::libraryPaths() should be used, instead of going from 
bin/foo to ../lib/*/ - ouch ;)
* Hopefully that takes care of the multiarch thing, so a lot code can be 
removed then.

The bit that surprises me is the servicetype check. I thought that the 
calligra/ subdir was enough to separate calligra plugins from other plugins. 
But maybe you have multiple types of plugins already. The thing is: it would 
then be faster to put them into subdirs of their own, e.g. 
plugins/calligra/parts/, plugins/calligra/spellchecking/ or whatever it is,
so that with a subdir name you can already filter the right kind of plugin.
Less Trader-like and more Qt-like, matter of choice I guess (but faster for 
sure).
 
-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5