On Sun, Jun 25, 2017 at 1:27 AM, David Faure <fa...@kde.org> wrote: > On samedi 24 juin 2017 11:52:22 CEST Marco Martin wrote: >> > from requiring Qt 5.7. >> > This Qt version difference creates an issue for the CI though, as can be >> > seen at https://build.kde.org/job/kirigami%20master%20stable-kf5-qt5/ >> >> so it could be released as a framework anyways, good >> If it helps, I could even let it build under 5.6, as everything that >> depends on 5.7 are qml files, which is a runtime dependency (on a 5.6 >> system would just install a bunch of dead code in form of qml files) >> Alternatively, there is still an old branch around that works on Qt >> 5.6, is pretty much dead, but we still do a bugfix in there every now >> and then, that one could be built on the 5.6 version of ci > > That's one solution. But I'm not sure that the new CI works the same way > anyway, maybe it solves this differently.
The new CI system uses the same platform for both current development and stable branches of a given Product at the moment, and in the case of Frameworks all three images (for Linux, FreeBSD and Windows) all use Qt 5.7. > >> uh, leftover, both checks on THEME can be removed safely > > OK, thanks. > >> as DESKTOP_ENABLED and PLASMA_ENABLED install stuff that has more >> dependencies (always runtime tough and just for the looks, never new >> api/functionality) is it ok leaving it there built conditionally >> (easier to maintain) or should be splitted in another repo? > > Seems fine to me. > >> > I noticed that DESKTOP_ENABLED installs a file called >> > styles/org.kde.desktop, which matches a runtime error I've seen for some >> > time now, e.g. at QtCreator >> startup: >> > QtCreator(12888)/default QQuickControlSettings1::QQuickControlSettings1: >> WARNING: Cannot find style "org.kde.desktop" - fallback: >> "/d/qt/5/kde/build/qtbase/qml/QtQuick/Controls/Styles/Desktop" >> >> basically kirigami has a style that is called org.kde.desktop for >> desktop systems, that matches the style we did for QtQuickControls2 >> for desktop systems as well, as Qt is not interested to do a desktop >> specific style for qtquickcontrols2 themselves, >> however, >> the environment variable to set the style of both qtquickcontrols1 and >> 2 style is QT_QUICK_CONTROLS_STYLE, which we set in startkde > > Right, that's set to org.kde.desktop indeed. > >> 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? > >> QtQuickControls1 at this moment doesn't find org.kde.desktop, so just >> falls back to its default "Desktop" and everything keeps working as >> expected. > > So the heart of the issue is that both QQC1 and QQC2 use the same environment > variable, which is kind of stupid because nothing guarantees that a style with > that name will exist for both. How about introducing a > QT_QUICK_CONTROLS_2_STYLE in Qt? > >> 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. > >> , 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. > >> > I enabled BUILD_EXAMPLES and got a nice example "kirigami2gallery" built >> > as a result, but why is it under the android subdirectory? >> >> 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. > >> 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). > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > Regards, Ben
