K_PLUGIN_FACTORY changes explained
Boudewijn Rempt
boud at valdyas.org
Sat Aug 31 08:59:33 UTC 2013
On Sat, 31 Aug 2013, David Faure wrote:
> 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
> ?
Because we didn't want to change a few hundred instances of
INSTALL(TARGETS myplugin DESTINATION ${PLUGIN_INSTALL_DIR})
at this moment -- because we're still adding new plugins and changing old
plugins in the 4.8-based branch we wanted to keep the changes as minimal
as possible.
> 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
Right
> * QCoreApplication::libraryPaths() should be used, instead of going from
> bin/foo to ../lib/*/ - ouch ;)
Well, that didn't work -- not without setting environment variables like
QT_PLUGIN_DIR. We did give it a try, but libraryPaths() actually didn't
return the path to the library directory. And we wanted to be independent
of environment variables here.
> * 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.
I think we've got about 20 servicetypes and about 300-400 plugins.
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).
Yes... I had thought of that, but then again, we'd need to change a lot of
existing code which makes merging from master harder :-(
Boud
More information about the Kde-frameworks-devel
mailing list