[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-frameworks-devel
Subject: Re: dependency issue (KService* -> KPluginLoader -> KLocale)
From: David Faure <faure () kde ! org>
Date: 2012-08-30 14:35:37
Message-ID: 3578319.rAQdHpFrbC () asterix ! site
[Download RAW message or body]
On Thursday 30 August 2012 11:01:42 Sune Vuorela wrote:
> On 2012-08-29, David Faure <faure@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, faure@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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic