> 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
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 ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126087/#review88463 ----------------------------------------------------------- On Nov. 16, 2015, 2: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, 2: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 > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
