2012/8/31 Kevin Ottens <er...@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@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel