Kirigami in Frameworks

[Marco Martin]

whops, forgot cc to kde-frameworks, resending
On Sat, Jun 24, 2017 at 10:58 AM, David Faure <faure at kde.org> wrote:
> On lundi 5 juin 2017 14:42:47 CEST Marco Martin wrote:
>> Hi all,
>> The Kirigami component set always was targeted to be eventually released as
>> a framework, ideally tier 1. since a framework must depend at most from 2
>> Qt releases before the current one, it couldn't be released there yet. Now
>> that Qt 5.9 is released
>
> Given the LTS nature of Qt 5.6 I'd like to keep 5.6 as a base requirement 
for the
> other frameworks for a bit longer if possible, but this doesn't prevent 
kirigami
> 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

>> It strictly depends just from Qt stuff, so should be tier 1 (at runtime it
>> can use optional styles that use features from Plasma, tough not having
>> plasma installed doesn't touch its functionality in any part, if this ends
>> up being a problem, i can move that style into plasma-integration)
>
> I just cleaned up the toplevel CMakeLists.txt a bit, but I found an issue 
there:

oh, thanks you 

> it checks for KF5Declarative_FOUND but doesn't do a find_package for that 
component, so this looks pretty useless.
> Since DESKTOP_ENABLED is on by default, what's the point of that 
if(KF5Declarative_FOUND AND THEME STREQUAL "System") ?

uh, leftover, both checks on THEME can be removed safely

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?

> 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

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.

QtQuickControls1 at this moment doesn't find org.kde.desktop, so just
falls back to its default "Desktop" and everything keeps working as
expected. One way to silence this could be when the qtquickcontrols2
theme installs into qt's qqc2, 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)

> 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.

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/ ?

--
Marco Martin