Re: Kirigami in Frameworks

[Marco Martin]

On Sunday 02 July 2017, David Faure wrote:
> 
> I'd like to finalize the tagging today.
> With kirigami still having issues with translations, CI, and naming, I'd
> like to skip it for now and release it next month, unless there are strong
> reasons to do otherwise.

I'm fine with this as well

-- 
Marco Martin

Re: Kirigami in Frameworks

[Marco Martin]

On Saturday 01 July 2017, David Faure wrote:
> On vendredi 30 juin 2017 15:16:17 CEST Marco Martin wrote:
> > 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?
> 
> Isn't this the right time to drop that historic baggage?

I'm fine with it

-- 
Marco Martin

Re: Kirigami in Frameworks

[Sebastian Kügler]

On zaterdag 1 juli 2017 11:27:21 CEST Albert Astals Cid wrote:
> https://websvn.kde.org/trunk/l10n-kf5/templates/messages/frameworks/libkirig
> ami2plugin_qt.pot?revision=1492189=markup
> 
> Disagrees with you

Ow, okay. I see, I only grepped for i18n, not for qsTr(), sorry for the noise!

> On ds., jul. 1, 2017 at 9:02, Sebastian Kügler
>  wrote:
> 
> On vrijdag 30 juni 2017 23:16:49 CEST Albert Astals Cid wrote:
> > What happened to the "no new strings after the first two weeks" rule?
> 
> Kirigami doesn't have any translatable strings.
-- 
sebas

http://www.kde.org | http://vizZzion.org

Re: Kirigami in Frameworks

[Rik Mills]

On 01/07/17 12:48, David Faure wrote:
> On vendredi 30 juin 2017 15:16:17 CEST Marco Martin wrote:
>> 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?
> 
> Isn't this the right time to drop that historic baggage?
> 
> I suppose it's not just the tarball name that ends with 2, but also the name 
> of what's extracted from it. Which means renaming the checkout, which breaks 
> the next run of kdesrc-build... lots of trouble.
> 
> If this framework was supposed to be called kirigami2, let's call it 
> kirigami2, otherwise I'd say, the tarball name is changing to kirigami.

Reverting to kirigami from kirigami2 could potentially cause issues in
ubuntu/kubuntu.

Re: Kirigami in Frameworks

[Luigi Toscano]

Il 02 luglio 2017 10:07:49 CEST, Rik Mills  ha scritto:
>On 01/07/17 12:48, David Faure wrote:
>> On vendredi 30 juin 2017 15:16:17 CEST Marco Martin wrote:
>>> 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?
>> 
>> Isn't this the right time to drop that historic baggage?
>> 
>> I suppose it's not just the tarball name that ends with 2, but also
>the name 
>> of what's extracted from it. Which means renaming the checkout, which
>breaks 
>> the next run of kdesrc-build... lots of trouble.
>> 
>> If this framework was supposed to be called kirigami2, let's call it 
>> kirigami2, otherwise I'd say, the tarball name is changing to
>kirigami.
>
>Reverting to kirigami from kirigami2 could potentially cause issues in
>ubuntu/kubuntu.

Which kind of issues exactly? (if there are, they may happen also in other 
distributions)

Ciao

-- 
Luigi

Re: Kirigami in Frameworks

[Luigi Toscano]

Il 02 luglio 2017 09:55:48 CEST, David Faure  ha scritto:
>On samedi 1 juillet 2017 13:48:28 CEST David Faure wrote:
>> On vendredi 30 juin 2017 15:16:17 CEST Marco Martin wrote:
>> > 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?
>> 
>> Isn't this the right time to drop that historic baggage?
>> 
>> I suppose it's not just the tarball name that ends with 2, but also
>the name
>> of what's extracted from it. Which means renaming the checkout, which
>> breaks the next run of kdesrc-build... lots of trouble.
>> 
>> If this framework was supposed to be called kirigami2, let's call it
>> kirigami2, otherwise I'd say, the tarball name is changing to
>kirigami.
>> 
>> CC'ing release-team for input.
>
>I'd like to finalize the tagging today.
>With kirigami still having issues with translations, CI, and naming,
>I'd like 
>to skip it for now and release it next month, unless there are strong
>reasons 
>to do otherwise.

Just for the record, translations have been moved almost immediately. The other 
issues are still relevant of course.

Ciao

-- 
Luigi

Re: Kirigami in Frameworks

[David Faure]

On samedi 1 juillet 2017 13:48:28 CEST David Faure wrote:
> On vendredi 30 juin 2017 15:16:17 CEST Marco Martin wrote:
> > 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?
> 
> Isn't this the right time to drop that historic baggage?
> 
> I suppose it's not just the tarball name that ends with 2, but also the name
> of what's extracted from it. Which means renaming the checkout, which
> breaks the next run of kdesrc-build... lots of trouble.
> 
> If this framework was supposed to be called kirigami2, let's call it
> kirigami2, otherwise I'd say, the tarball name is changing to kirigami.
> 
> CC'ing release-team for input.

I'd like to finalize the tagging today.
With kirigami still having issues with translations, CI, and naming, I'd like 
to skip it for now and release it next month, unless there are strong reasons 
to do otherwise.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: Kirigami in Frameworks

[David Faure]

On vendredi 30 juin 2017 15:16:17 CEST Marco Martin wrote:
> 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?

Isn't this the right time to drop that historic baggage?

I suppose it's not just the tarball name that ends with 2, but also the name 
of what's extracted from it. Which means renaming the checkout, which breaks 
the next run of kdesrc-build... lots of trouble.

If this framework was supposed to be called kirigami2, let's call it 
kirigami2, otherwise I'd say, the tarball name is changing to kirigami.

CC'ing release-team for input.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: Kirigami in Frameworks

[Albert Astals Cid]

https://websvn.kde.org/trunk/l10n-kf5/templates/messages/frameworks/libkirigami2plugin_qt.pot?revision=1492189=markup
Disagrees with you 
Sent from Yahoo Mail on Android 
 
  On ds., jul. 1, 2017 at 9:02, Sebastian Kügler wrote:   On 
vrijdag 30 juni 2017 23:16:49 CEST Albert Astals Cid wrote:
> What happened to the "no new strings after the first two weeks" rule?

Kirigami doesn't have any translatable strings.
-- 
sebas

http://www.kde.org | http://vizZzion.org
  

Re: Kirigami in Frameworks

[Sebastian Kügler]

On vrijdag 30 juni 2017 23:16:49 CEST Albert Astals Cid wrote:
> What happened to the "no new strings after the first two weeks" rule?

Kirigami doesn't have any translatable strings.
-- 
sebas

http://www.kde.org | http://vizZzion.org

Re: Kirigami in Frameworks

[Albert Astals Cid]

El divendres, 30 de juny de 2017, a les 15:16:17 CEST, Marco Martin va 
escriure:
> Hi,
> I have moved it, should be good to go.

Yeah let's do everything last minute, for sure translations will be moved fine 
and all will be great.

What happened to the "no new strings after the first two weeks" rule?

Please release it next month.

Cheers,
  Albert

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

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

Re: Kirigami in Frameworks

[David Faure]

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

Re: Kirigami in Frameworks

[Marco Martin]

On Sat, Jun 24, 2017 at 3:27 PM, David Faure  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

Re: Kirigami in Frameworks

[Ben Cooksley]

On Sun, Jun 25, 2017 at 8:44 AM, David Faure  wrote:
> On samedi 24 juin 2017 11:15:25 CEST Ben Cooksley wrote:
>> Please check the new CI at https://build-sandbox.kde.org/ for the
>> current state of affairs.
>
> This doesn't appear to have kirigami at all?

Kirigami is currently in Extragear, and coverage for Extragear
projects must be explicitly requested by the maintainers of a project
(as outlined in my prior emails regarding the new CI). No such request
has been received for Kirigami.

>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>

Cheers,
Ben

Re: Kirigami in Frameworks

[David Faure]

On samedi 24 juin 2017 11:15:25 CEST Ben Cooksley wrote:
> Please check the new CI at https://build-sandbox.kde.org/ for the
> current state of affairs.

This doesn't appear to have kirigami at all?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: Kirigami in Frameworks

[Ben Cooksley]

On Sun, Jun 25, 2017 at 1:27 AM, David Faure  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

Re: Kirigami in Frameworks

[Marco Martin]

whops, forgot cc to kde-frameworks, resending
On Sat, Jun 24, 2017 at 10:58 AM, David Faure  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

Re: Kirigami in Frameworks

[Ben Cooksley]

On Sat, Jun 24, 2017 at 8:58 PM, David Faure <fa...@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/

Please check the new CI at https://build-sandbox.kde.org/ for the
current state of affairs.
As the requirements around Qt 4 and some other things have now been
sorted I intend to switch it over to become production in the next 24
hours.

>
>> i would like to propose to move Kirigami in
>> frameworks, to be relased in the main release cycle, and stop standalone
>> releases from extragear.
>>
>> 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:
> 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") ?
>
> 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"
>
> I enabled BUILD_EXAMPLES and got a nice example "kirigami2gallery" built as a 
> result, but why is it under the android subdirectory?
> (The good thing about this example is now I finally have an idea what 
> kirigamy is about. The name doesn't really say much ;))
>

Cheers,
Ben

> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>

Re: Kirigami in Frameworks

[David Faure]

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/

> i would like to propose to move Kirigami in
> frameworks, to be relased in the main release cycle, and stop standalone
> releases from extragear.
> 
> 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:
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") ?

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"

I enabled BUILD_EXAMPLES and got a nice example "kirigami2gallery" built as a 
result, but why is it under the android subdirectory?
(The good thing about this example is now I finally have an idea what kirigamy 
is about. The name doesn't really say much ;))

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: Kirigami in Frameworks

[Marco Martin]

On Wed, Jun 21, 2017 at 6:22 PM, Jonathan Riddell  wrote:
> On 21 June 2017 at 15:00, Marco Martin  wrote:
>> As there were no replies for quite a while, i assume there are no
>> particular objections.
>>
>> so, how to proceed? what needs to be doe to do the actual move?
>
> Does it comply with the policies (as much as they are relevant for QML)?
> https://community.kde.org/Frameworks/Policies

yeah, it should for pretty much all rules

> Get David Faure to give his approval then see what the reponse to my
> "who is authorised to move repos around?" thead is.
> https://marc.info/?l=kde-core-devel=149806172721190=2



ok, waiting David's comment on it.

--
Marco Martin

Re: Kirigami in Frameworks

[Jonathan Riddell]

On 21 June 2017 at 15:00, Marco Martin  wrote:
> As there were no replies for quite a while, i assume there are no
> particular objections.
>
> so, how to proceed? what needs to be doe to do the actual move?

Does it comply with the policies (as much as they are relevant for QML)?
https://community.kde.org/Frameworks/Policies

Get David Faure to give his approval then see what the reponse to my
"who is authorised to move repos around?" thead is.
https://marc.info/?l=kde-core-devel=149806172721190=2

Jonathan

Re: Kirigami in Frameworks

[Marco Martin]

As there were no replies for quite a while, i assume there are no
particular objections.

so, how to proceed? what needs to be doe to do the actual move?

On Mon, Jun 5, 2017 at 2:42 PM, Marco Martin <notm...@gmail.com> 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, i would like to propose to move Kirigami in
> frameworks, to be relased in the main release cycle, and stop standalone
> releases from extragear.
>
> 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)
>
> --
> Marco Martin

Kirigami in Frameworks

[Marco Martin]

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, i would like to propose to move Kirigami in 
frameworks, to be relased in the main release cycle, and stop standalone 
releases from extragear.

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)

-- 
Marco Martin