Review Request 126087: Move the i18n context from KDeclarative

[Aleix Pol Gonzalez]

> On Nov. 17, 2015, 10: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++

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.


- Aleix


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126087/#review88463
-----------------------------------------------------------


On Nov. 16, 2015, 3:55 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. 16, 2015, 3:55 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
> -----
> 
>   src/klocalizedcontext.cpp PRE-CREATION 
>   src/CMakeLists.txt 818595e 
>   src/klocalizedcontext.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126087/diff/
> 
> 
> Testing
> -------
> 
> Ported KDeclarative, everything still seems to work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151117/483c821e/attachment.html>