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. > 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. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
