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. Pro for 1: kservice is apps and plugins, so loading plugins is part of the same framework. When Qt-5.1 gets a proper trader equivalent, and once I write the libxdg-cache-based application lookup, we can migrate the apps and plugins to that, and slowly phase out kservice. Con for 1: KPluginLoader itself depends on KLocale, since it automatically inserts the translation catalog for the plugin. I think that's a good feature, it's part of what makes klocale superior to qtranslator, so the only solution would be that kservice is tier2, and depends on the klocale framework. The downside is that the users of KService as an application descriptor (kopenwithdialog, krun, kded vfolder, open-or-save dialog...) are getting an unwanted dependency. Pro for 2: solves the dependency issue, although then we still need to find a home for KPluginLoader, and that home will be a tier2 [solved by solution 3]. Con for 2 and 3: SIC change, and a weird one: although the KService template can easily move to KPluginLoader (which already knows about KService, so this would just be an extra convenience method), KMimeTypeTrader::createInstanceFromQuery really belongs in KMimeTypeTrader IMHO. Well, we could have KPluginLoader::createInstanceFromMimeTypeQuery and createInstanceFromServiceTypeQuery, but this is getting long, not very OOP, and it seems like a bit of a reverse depedency hack to put that into the plugin loader itself (you do the trader query first, and then the plugin loading). To the app developer's point of view, direct plugin loading ("load foo.so") is *more* low-level than the trader which can also load plugins... or maybe this is just dinosaur-thinking, one could say "the trader is an implementation detail of the high-level KPluginLoader all-in-one method" :-) Con for 3: no idea where that would be, and it's starting to look like weird API for the benefit of cutting dependencies. Possibly for no good purpose in this case. 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... I had started in the direction of solution 2, because it was ok for the kservice template method, but moving the trader ones seems really strange to me, so I stopped to write this thinking-out-loud email :-) I think I'll reverse that and go for solution 1 then, i.e. moving kpluginloader and making kservice tier2. (Or possibly solution 1b?) If this is indeed "temporary" because the proper kf5/qt5 solution is the qt plugin metadata querying stuff anyway, then it doesn't matter this much, I guess (the kservice framework will be kept for compatibility in any case, we have a huge amount of apps and plugins depending on it). Well, I guess I answered my own (implicit) question here, but if someone has a better idea I'm listening :-) -- 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