Hi, I have moved it, should be good to go. one sidenote (hoping is not a problem) for historical reasons, the tarballs were called kirigami2-version instead of just kirigami (or distributions may have some problems in upgrading).. do release scripts need to be adapted in some way?
On Fri, Jun 30, 2017 at 2:44 PM, David Faure <fa...@kde.org> wrote: > What's the status with the move of Kirigami to frameworks? > Do we want it in 5.36 tomorrow? > > AFAICS it's still in extragear/libs/kirigami in kde_projects.xml. > > David. > > On lundi 26 juin 2017 11:25:08 CEST Marco Martin wrote: >> On Sat, Jun 24, 2017 at 3:27 PM, David Faure <fa...@kde.org> wrote: >> >> the default style for QtQuickControlsStyle1 is "Desktop" >> >> we could have called this style "Desktop" as well so all would have >> >> aligned nicely, but that could be quite dangerous, as Qt coulddecide >> >> any moment that they indeed want to do a style called "Desktop" for >> >> qqc2, at which point it would conflict, so having the org.kde prefix >> >> was the safe route. >> > >> > Well, we could also rename ours when/if the conflict occurs? >> >> since the conflict would be of installed files, it would make released >> version not installable, which looks to me like too big of a risk. >> >> >> One way to silence this could be when the qtquickcontrols2 >> >> theme installs into qt's qqc2 >> > >> > If you mean $QTDIR, that's not my case. The plugin is found via >> > QML2_IMPORT_PATH I suppose. >> >> qtquickcontrols2 will be installed under QML2_IMPORT_PATH and we need >> to install under that folder >> >> >> , to install also an org.kde.desktop >> >> symlink in QtQuickControls1 that just points to "Desktop" (note that >> >> style is not in the kirigami repository, kirigami has themes with the >> >> same name because it's an extension on top of qtquickcontrols2) >> > >> > That sounds good, if it can be done. >> >> setting a symlink there seems to just work, so i would try to go for that >> route >> >> It has some android specific things, like providing a manifest.xml and >> >> some optional qtandroidextras usage for integration when compiled >> >> there, but it's intended to be multiplatform, so may make sesie to >> >> enable it. >> > >> > Then I don't think it should be under an android subdir. >> > A multiplatform app with extra stuff for android integration is still >> > multiplatform in the first place. >> >> sure, renaming it to multipletform then :) >> >> >> talking about examples, do you think is better to build them with a >> >> flag on the top cmake as is now, or provide a separate standalone >> >> cmake file under examples/ ? >> > >> > Much better the way you did it, it's how I see it done in most other >> > frameworks. >> > It makes it easy to enable the building of examples once and for all in >> > kdesrc-buildrc for instance, to make sure they keep compiling and so that >> > they are available for testing. >> > In fact, I wonder if the CI shouldn't set BUILD_EXAMPLES=ON in all >> > frameworks that have that option... (4 currently, 5 with kirigami). >> >> ok >> >> -- >> Marco Martin > > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 >
