> On Nov. 17, 2015, 9:58 a.m., Marco Martin wrote:
> > Here's the reason I don't like it:
> > In origin KDeclarative was intended to be a library that only depended from
> > Qt stuff, to be at most tier 2 (and imports there were supposed to be
> > qt-only as well) and frameworks applications using QML were supposed to do
> > it trough KDeclarative..
> > This just highlights a problem happened afterwards, when no frameworks
> > maintainer wanted any qml binding it the framework's repository, the
> > kdeclarative repo ended up being pretty much a dumpster where all the
> > binding of all the frameworks went, making it depend from pretty much
> > everything.
> > This also means that whoever will need the binding of $framework, it will
> > probably rather rewrite them, since using kdeclarative means pretty much
> > depending from all of them.
> > So, fine for making the i18n context independent, but iff the whole
> > situation gets resolved and each single import that depends from more than
> > Qt stuff goes either in its framework repository or gets its own.
>
> Martin Gräßlin wrote:
> I agree with Marco: we should try to split this up again. Somehow the
> framework starts to remind me of kdelibs4 and in applications I maintain it
> takes a lot of strength to buy into using it. (Why would I want KIO in KWin?)
>
> Aleix Pol Gonzalez wrote:
> Isn't it what this patch is about?
>
> To me it's clear that KIconProvider could go to KIconThemes and
> KIOAccessManagerFactory could go to KIO.
>
> Marco Martin wrote:
> we could push that right at the start of the 5.18 cycle so that's done
> well in advance
>
> Marco Martin wrote:
> yes, and most of the linking luckily is private. the only thing that is
> public and a bit out of tune unfortunately is configpropertymap
>
> Marco Martin wrote:
> in general i'm in favor, i would like to try to make it an import instead
> tough (the qobject inserted as context object if a custom one wasn't set
> already and made a QML singleton as well, so that can get accessed by
> KI18n.i18n("") and such).
> it should work if it can be injected somehow from KDeclarative c++
>
> Aleix Pol Gonzalez wrote:
> If we do it in a different way (e.g. a singleton), we'll have to get the
> code ported. That's not backwards-compatible.
to stay compatible, kdeclarative could try to load the plugin on the engine,
and should be the same as directly setting the context object
- Marco
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126087/#review88463
-----------------------------------------------------------
On Nov. 18, 2015, 12:26 p.m., Aleix Pol Gonzalez wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126087/
> -----------------------------------------------------------
>
> (Updated Nov. 18, 2015, 12:26 p.m.)
>
>
> Review request for KDE Frameworks, Chusslove Illich and Marco Martin.
>
>
> Repository: ki18n
>
>
> Description
> -------
>
> The only way to use `i18n*()` so far in QML is by depending on all
> KDeclarative. This patch moves the necessary bits there so it can be adopted
> by an application or framework just by offering the needed bits within KI18n.
> This is done by offering an object with methods that map to the `i18n*()` C++
> counter-parts.
>
>
> Diffs
> -----
>
> docs/programmers-guide.md 13a5f9d
> src/CMakeLists.txt 818595e
> src/klocalizedcontext.h PRE-CREATION
> src/klocalizedcontext.cpp PRE-CREATION
>
> Diff: https://git.reviewboard.kde.org/r/126087/diff/
>
>
> Testing
> -------
>
> Ported KDeclarative, everything still seems to work.
>
>
> Thanks,
>
> Aleix Pol Gonzalez
>
>
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
