On 2012-08-29, David Faure <fa...@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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel