dependency issue (KService* -> KPluginLoader -> KLocale)

[David Faure]

On Thursday 30 August 2012 11:01:42 Sune Vuorela wrote:
> On 2012-08-29, David Faure <faure at 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 at ...

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5