[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: dependency issue (KService* -> KPluginLoader -> KLocale)
From:       Kevin Ottens <ervin () kde ! org>
Date:       2012-08-31 16:39:11
Message-ID: 103588218.jruKror5vA () wintermute
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 31 August 2012 18:26:24 Dario Freddi wrote:
> 2012/8/31 Kevin Ottens <ervin@kde.org>:
> > On Wednesday 29 August 2012 23:53:32 David Faure wrote:
> >> 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.
> 
> To be honest I don't really agree here - I don't see a real benefit in
> avoiding the KLocale dependency

Think third parties reusability. The benefit is maximizing the possibility for 
it.

> and I think it makes sense to have the plugin system depend on it -

Sure...

> even though I reckon that might be undesirable in case a plugin bears no
> strings.

... and we have a potential solution, would be unfortunate to not try it. :-)

Now if that was a case of "the framework can't work without the dependency" 
I'd have a position similar to your. But here it's depending on the nature of 
the plugins, not on what the framework itself needs, that's what rings the 
"worth doing it" to me.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com

["signature.asc" (application/pgp-signature)]

_______________________________________________
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]