On Thursday 30 August 2012 11:01:42 Sune Vuorela wrote: > 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).
Exactly. Completely agreed. Well, it has another use, as mentionned: finding applications (from their desktop file, or from trader queries). But for this, too, I plan to offer a different solution later on (one like mimetypes: a binary cache updated at install time, see libxdg on the xdg list). But that's fine. One framework can offer two features :) > I agree that 3 looks weird and seems to add complexity to add > complexity. There is nothing wrong with being a tier2 library. No, but it would be wrong if we wanted to support the Qt translation system in KDE plugins rather than KLocale. However, now that I realized how limited it is (no way to autoload catalogs, for lack of standard paths and namings and language names), I'd say this isn't wanted/needed in this framework (only in very basic tier1 frameworks like karchive). And as long as we don't release, we can still move stuff around if things change anyway :) > 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) :-) Thank you for your confirmation, I feel less "alone making important decisions"! PS: I still can't whitelist you for this mailing-list, maybe due to nospam@... -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel