Kirigami in Frameworks

[David Faure]

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.

> 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