Re: qqc2-desktop-style as framework
On Sat, Oct 14, 2017 at 1:41 PM, Volker Krause wrote: > Observations while trying to add this to the KF5 Yocto recipes: > - it shows up as Tier 1 on https://api.kde.org/frameworks/index.html but seems > to have a hard dependency on Kirigami shoud be tier 3 (should have be fixed now) > - it seems to be licensed LGPLv3 + GPLv2, which doesn't match what https:// > community.kde.org/Policies/Licensing_Policy says about KF5 code (see item 4). yes, unfortunately had to take some code from Qt, therefore the license. it was decided thatwas ok as is not a library but something purely runtime (being a style not even something that is explicitly imported) so anything ending up using it couldn't be considered "derivative" in any way -- Marco Martin
Re: qqc2-desktop-style as framework
On Thursday, 31 August 2017 17:06:46 CEST Marco Martin wrote: > Hi all, > we have a qtquickcontrols style that is right now in workspace (unrelased, > to be released with Plasma 5.11) > it makes controls paint with qstyle to give it a reasonable desktop > appearance, plus some fixes/workarounds to make qml a bit more desktop > friendly (for instance fixes scrollwheel issues with Flickable) > sice it's pretty much untenable to make a desktop application with > QtQuickControls2 without it and make it look anything near "native", so > releasing it together plasma is probably not enough. > Applications using kirigami should be able to explicitly depend from it if > they want, to require a native-looking look and feel on linux desktops (even > on gnome would look already marginally better than with the stock > "universal" or "material" styles) > > it's a thing with no api, no libraries (not even an import, qqc2 styles work > a bit differently), so as with kirigami only source compatibility on the > qml- side will matter > > any objection into pulling it into a framework? anything particular for the > procedure? Observations while trying to add this to the KF5 Yocto recipes: - it shows up as Tier 1 on https://api.kde.org/frameworks/index.html but seems to have a hard dependency on Kirigami - it seems to be licensed LGPLv3 + GPLv2, which doesn't match what https:// community.kde.org/Policies/Licensing_Policy says about KF5 code (see item 4). Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: qqc2-desktop-style as framework
Mh > set(CMAKE_LIBRARY_OUTPUT_DIRECTORY I don't think that will do for production. "This property specifies the directory into which library target files should be built. Multi-configuration generators (VS, Xcode) append a per-configuration subdirectory to the specified directory." I *think* the easiest way to get this behavior is to still also adjust the source tree. Namely, if you have the add_library in src/org/kde/kirigami.2/CMakeLists.txt that will end up in $build/org/kde/kirigami.2/foo.so no matter what. I am too tired to check that though, so I may be talking nonesense here. Albert raises a good point, which I think would be fixed by not using a glob but listing all files explicitly (which should make `make` automatically rerun cmake on account of changed files). Alternatively to solve both problems the "install into builddir" logic could be outsourced into a standalone cmake helper which you manually call through a custom target. That way the target can always bedirty (run for every make thus keeping the builddir up to date) AND you can use install() to get the .so to where you want it to be without having to meddle with the source tree at all. HS
Re: qqc2-desktop-style as framework
El dimarts, 12 de setembre de 2017, a les 22:11:14 CEST, Marco Martin va escriure: > this is a quick and dirty attempt at this.. > i don't know how much it would break, but i think in order to have a > correct import usable without install it should do something along the > lines Do I read correctly that files are only copied at cmake time? They should rather be copied on make time so that if you edit a file and run make again it gets copied again and you don't need to rerun cmake, no? Cheers, Albert > > On Tue, Sep 12, 2017 at 8:49 PM, Marco Martin wrote: > > On Mon, Sep 11, 2017 at 4:59 PM, Harald Sitter wrote: > >> Another option I can think of is "installing" to the build directory > >> during cmake stage (i.e. construct a qml import path in > >> $CMAKE_BINARY_DIR). That's only more complicated and altogether meh > >> though, compared to simply adjusting the source tree. It also makes > >> the cmake stage take longer :'< > > > > uuh, I actually like it, I'll give it a try.. as i think just > > adjusting the source tree wouldn't be enough, as the qml plugin is > > comprised by qml files *and* a c++ plugin, which needs to be installed > > together the source qml files? > > > > so this way would put everything togetether > > > > -- > > Marco Martin
Re: qqc2-desktop-style as framework
this is a quick and dirty attempt at this..
i don't know how much it would break, but i think in order to have a
correct import usable without install it should do something along the
lines
On Tue, Sep 12, 2017 at 8:49 PM, Marco Martin wrote:
> On Mon, Sep 11, 2017 at 4:59 PM, Harald Sitter wrote:
>> Another option I can think of is "installing" to the build directory
>> during cmake stage (i.e. construct a qml import path in
>> $CMAKE_BINARY_DIR). That's only more complicated and altogether meh
>> though, compared to simply adjusting the source tree. It also makes
>> the cmake stage take longer :'<
>
>
>
> uuh, I actually like it, I'll give it a try.. as i think just
> adjusting the source tree wouldn't be enough, as the qml plugin is
> comprised by qml files *and* a c++ plugin, which needs to be installed
> together the source qml files?
>
> so this way would put everything togetether
>
> --
> Marco Martin
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 289b778..a19a27e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -48,6 +48,10 @@ include(KDEInstallDirs)
include(KDECMakeSettings)
include(KDECompilerSettings NO_POLICY_SCOPE)
+file(MAKE_DIRECTORY {CMAKE_BINARY_DIR}/bin/org/kde/kirigami.2)
+set(CMAKE_LIBRARY_OUTPUT_DIRECTORY
"${CMAKE_BINARY_DIR}/bin/org/kde/kirigami.2")
+#set(CMAKE_BINARY_DIR ${CMAKE_BINARY_DIR}/org/kde/kirigami.2)
+
set(CMAKECONFIG_INSTALL_DIR "${KDE_INSTALL_CMAKEPACKAGEDIR}/KF5Kirigami2")
configure_package_config_file(
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 408e656..902fb67 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -24,6 +24,17 @@ ELSE(STATIC_LIBRARY)
add_library(kirigamiplugin SHARED ${kirigami_SRCS})
target_link_libraries(kirigamiplugin Qt5::Core Qt5::Qml Qt5::Quick)
+
+file(GLOB RUNTIME_FILES
+ "controls/*"
+)
+file(GLOB STYLE_FILES
+ "styles/*"
+)
+file(MAKE_DIRECTORY {CMAKE_BINARY_DIR}/bin/org/kde/kirigami.2)
+file(COPY ${RUNTIME_FILES} DESTINATION
${CMAKE_BINARY_DIR}/bin/org/kde/kirigami.2)
+file(COPY ${STYLE_FILES} DESTINATION
${CMAKE_BINARY_DIR}/bin/org/kde/kirigami.2/styles)
+
install(TARGETS kirigamiplugin DESTINATION
${KDE_INSTALL_QMLDIR}/org/kde/kirigami.2)
install(DIRECTORY controls/ DESTINATION
${KDE_INSTALL_QMLDIR}/org/kde/kirigami.2)
Re: qqc2-desktop-style as framework
On Mon, Sep 11, 2017 at 4:59 PM, Harald Sitter wrote: > Another option I can think of is "installing" to the build directory > during cmake stage (i.e. construct a qml import path in > $CMAKE_BINARY_DIR). That's only more complicated and altogether meh > though, compared to simply adjusting the source tree. It also makes > the cmake stage take longer :'< uuh, I actually like it, I'll give it a try.. as i think just adjusting the source tree wouldn't be enough, as the qml plugin is comprised by qml files *and* a c++ plugin, which needs to be installed together the source qml files? so this way would put everything togetether -- Marco Martin
Re: qqc2-desktop-style as framework
On Monday, 11 September 2017 16:18:40 CEST Jonathan Riddell wrote: > I've moved qqc2-desktop-style to frameworks from kde/workspace, please > move the translations to follow No translations to move. Ciao -- Luigi
Re: qqc2-desktop-style as framework
On Mon, Sep 11, 2017 at 4:16 PM, Marco Martin wrote: > On Sun, Sep 10, 2017 at 3:41 PM, David Faure wrote: >> Sounds OK to me, get it moved to frameworks/ so it can be included in the >> next >> release. >> >> I notice there are no unittests (but that's always a bit hard for pure-gui >> stuff). On the other hand, please do take a look at the issue of `make >> uninstall ; make test` in kirigami first, it's still broken. > > ok, so the only way i think is to move the source tree to > src/org/kde/kirigami.2 i guess? Another option I can think of is "installing" to the build directory during cmake stage (i.e. construct a qml import path in $CMAKE_BINARY_DIR). That's only more complicated and altogether meh though, compared to simply adjusting the source tree. It also makes the cmake stage take longer :'< HS
qqc2-desktop-style as framework
I've moved qqc2-desktop-style to frameworks from kde/workspace, please move the translations to follow Jonathan
Re: qqc2-desktop-style as framework
On Sun, Sep 10, 2017 at 3:41 PM, David Faure wrote: > Sounds OK to me, get it moved to frameworks/ so it can be included in the next > release. > > I notice there are no unittests (but that's always a bit hard for pure-gui > stuff). On the other hand, please do take a look at the issue of `make > uninstall ; make test` in kirigami first, it's still broken. ok, so the only way i think is to move the source tree to src/org/kde/kirigami.2 i guess? -- Marco Martin
Re: qqc2-desktop-style as framework
On vendredi 1 septembre 2017 15:02:16 CEST Marco Martin wrote: > On Thu, Aug 31, 2017 at 5:06 PM, Marco Martin wrote: > > any objection into pulling it into a framework? anything particular for > > the procedure? > > as an update to that, i've update its cmake files and metadata files > to be coherent with other frameworks, at this point i'll wait a couple > of weeks if there are complaints, then if not it can be merged in > frameworks? ideal would be aiming for october release Sounds OK to me, get it moved to frameworks/ so it can be included in the next release. I notice there are no unittests (but that's always a bit hard for pure-gui stuff). On the other hand, please do take a look at the issue of `make uninstall ; make test` in kirigami first, it's still broken. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: qqc2-desktop-style as framework
On Fri, Sep 1, 2017 at 3:02 PM, Marco Martin wrote: > On Thu, Aug 31, 2017 at 5:06 PM, Marco Martin wrote: >> any objection into pulling it into a framework? anything particular for the >> procedure? > > as an update to that, i've update its cmake files and metadata files > to be coherent with other frameworks, at this point i'll wait a couple > of weeks if there are complaints, then if not it can be merged in > frameworks? ideal would be aiming for october release any update on this? is there anything i have to change there? -- Marco Martin
Re: qqc2-desktop-style as framework
On Thu, Aug 31, 2017 at 5:06 PM, Marco Martin wrote: > any objection into pulling it into a framework? anything particular for the > procedure? as an update to that, i've update its cmake files and metadata files to be coherent with other frameworks, at this point i'll wait a couple of weeks if there are complaints, then if not it can be merged in frameworks? ideal would be aiming for october release -- Marco Martin
Re: qqc2-desktop-style as framework
Hi, from my perspective as app dev: As it currently stands I can only get proper desktop scrolling by either shipping an app-specific hack or by forcing Marco's style. The only way I can reasonably force it is if I can also depend on it, and if it's a framework, I can depend on it in CMake, causing packagers (including e.g. Windows) to roll it in. So I'd +1. Cheers, Eike On 09/01/2017 12:06 AM, Marco Martin wrote: > Hi all, > we have a qtquickcontrols style that is right now in workspace (unrelased, to > be released with Plasma 5.11) > it makes controls paint with qstyle to give it a reasonable desktop > appearance, plus some fixes/workarounds to make qml a bit more desktop > friendly > (for instance fixes scrollwheel issues with Flickable) > sice it's pretty much untenable to make a desktop application with > QtQuickControls2 without it and make it look anything near "native", so > releasing it together plasma is probably not enough. > Applications using kirigami should be able to explicitly depend from it if > they want, to require a native-looking look and feel on linux desktops (even > on gnome would look already marginally better than with the stock "universal" > or "material" styles) > > it's a thing with no api, no libraries (not even an import, qqc2 styles work > a > bit differently), so as with kirigami only source compatibility on the qml- > side will matter > > any objection into pulling it into a framework? anything particular for the > procedure? >
qqc2-desktop-style as framework
Hi all, we have a qtquickcontrols style that is right now in workspace (unrelased, to be released with Plasma 5.11) it makes controls paint with qstyle to give it a reasonable desktop appearance, plus some fixes/workarounds to make qml a bit more desktop friendly (for instance fixes scrollwheel issues with Flickable) sice it's pretty much untenable to make a desktop application with QtQuickControls2 without it and make it look anything near "native", so releasing it together plasma is probably not enough. Applications using kirigami should be able to explicitly depend from it if they want, to require a native-looking look and feel on linux desktops (even on gnome would look already marginally better than with the stock "universal" or "material" styles) it's a thing with no api, no libraries (not even an import, qqc2 styles work a bit differently), so as with kirigami only source compatibility on the qml- side will matter any objection into pulling it into a framework? anything particular for the procedure? -- Marco Martin
