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

[Sune Vuorela]

On 2012-08-29, David Faure <faure at kde.org> 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.

<snip reasons>

First, I stopped temporarily reading here thinking that 1) sounds like
the good approach, becuse what is the service/trader framework for if
not loading plugins (and data).

I agree that 3 looks weird and seems to add complexity to add
complexity. There is nothing wrong with being a tier2 library.


1b - a KPluginLoader::PluginCatalogLoadedSignalEmitterSingleton class do 
look abit ugly. (yes, I know a better name could be found, but that
doesn't make the concept a bit ugly - and I even kind of like
singletons)

I'm also thinking that going the way of least resistance regarding api
changes is a good way, especially if the qtpluginmagic is going to be
good enough.


> Well, I guess I answered my own (implicit) question here, but if someone has a 
> better idea I'm listening :-)

I don't have better ideas, but I can write a letter of support :) - or a
sanity check or whatever.

/Sune
 - holder of sanity