Kirigami in Frameworks

[Marco Martin]

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 <faure at 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 <faure at 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, faure at kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>