Kirigami in Frameworks

[Ben Cooksley]

On Sun, Jun 25, 2017 at 1:27 AM, David Faure <faure at 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, faure at kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>

Regards,
Ben