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

[Kevin Ottens]

On Friday 31 August 2012 18:26:24 Dario Freddi wrote:
> 2012/8/31 Kevin Ottens <ervin at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120831/23741b7b/attachment.sig>