Re: Kirigami in Frameworks
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
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
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&view=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
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
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
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
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
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
https://websvn.kde.org/trunk/l10n-kf5/templates/messages/frameworks/libkirigami2plugin_qt.pot?revision=1492189&view=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
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
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 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 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
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 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 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
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 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
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
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
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
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
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, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: Kirigami in Frameworks
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
On Sat, Jun 24, 2017 at 8:58 PM, 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/ 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
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
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&m=149806172721190&w=2 ok, waiting David's comment on it. -- Marco Martin
Re: Kirigami in Frameworks
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&m=149806172721190&w=2 Jonathan
Re: Kirigami in Frameworks
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 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
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