dependency issue (KService* -> KPluginLoader -> KLocale)

Dario Freddi drf54321 at gmail.com
Fri Aug 31 16:26:24 UTC 2012


2012/8/31 Kevin Ottens <ervin at kde.org>:
> Hello,
>
> On Wednesday 29 August 2012 23:53:32 David Faure wrote:
>> KService, KServiceTypeTrader and KMimeTypeTrader (all of which I moved to a
>> new "kservice" framework), all have a template method (createInstance*)
>> which uses KPluginLoader to load the plugin described by the given service,
>> or trader query.
>>
>> Which gives two, well, three solutions:
>>
>> 1) Moving KPluginLoader to the kservice framework as well.
>>
>> 2) Moving these template methods out, e.g. into KPluginLoader itself, making
>> kpluginloader one tier above kservice. the app code change looks like this:
>> -  Client *client = service->createInstance<Client>(this, ...)
>> + Client *client = KPluginLoader::createInstance<Client>(service, this, ...)
>>
>> 3) Making kservice *and* kpluginloader tier1 libs, and having the template
>> methods to integrate the two somewhere else, above.
>
> I definitely vote for 1. I don't see much use for KPluginLoader outside of a
> "I use kservice" context. With that in mind, 2 and 3 are far less tempting.

Add my vote in as well.

>> Hmm.... another idea:
>> Solution 1b: move KPluginLoader to kservice, but solve the i18n dependency
>> by having some singleton inside KPluginLoader emit a signal when loading a
>> plugin, and some singleton in KLocale picks that up and loads the catalog.
>> Too hacky? (ugly singletons, and exposing some internal object publically
>> for the benefit of one other framework)... It would work, though, I
>> guess...
>
> If we can make it work that's worth a try despite the Qt translation system
> being "inferior". I can easily imagine cases of plugins with no strings of
> their own. In such a case forcibly bringing klocale as a dependency is a bit
> unfortunate if it can be avoided.

To be honest I don't really agree here - I don't see a real benefit in
avoiding the KLocale dependency and I think it makes sense to have the
plugin system depend on it - even though I reckon that might be
undesirable in case a plugin bears no strings. Also, I think tier2
fits quite well for kservice. I think the original solution by David
is already good enough to go. (my 2c)

>
> Regards.
> --
> Kévin Ottens, http://ervin.ipsquad.net
>
> KDAB - proud patron of KDE, http://www.kdab.com
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>


More information about the Kde-frameworks-devel mailing list