Sun, Sep 17
I don't know if is related to this commit, but when compiling my application via kirigami with make create-* and uploading to my cellphone, a white screen appears.
Using adb to debug with logcat, this error took my attention: libatcore-gui.so: qrc:///main.qml:2 ((null)): qrc:///main.qml:2:1: module "QtQuick.Controls" plugin "qtquickcontrols2plugin" not found, and than searching about it, this site took my attention.
I don't know if it's a bug or related to this PR.
Diff updated to move library target definition after find_package_handle_standard_args.
Sat, Sep 16
Looks good. What's your migration plan ?
if you don't want to bump the ECM requirements for applications looking for pulseaudio, you have to set some compatibility/deprecated vars (eg: kmix uses uppercase variables)
Fri, Sep 15
Updated as per review comments.
Modules updated with standard header, documentation and copyright; endif() used throughout.
-1. They don't match the ECM coding style and code quality (doc, license, endif(), pkgconfig...)
Thu, Sep 14
It's the same source really - the only differences between those in kdelibs4support and ecm/attic are that the former uses endif(same_as_if) and the latter uses endif().
Nothing else within Frameworks, Plasma or applications uses anything from ecm/attic directly.
In other words, your suggestion is not to add it to ecm, but to move it from attic/modules to find-modules.
Fri, Sep 8
My suggestion would be to focus any review efforts in this order:
My comments here are phrased as if this SIP-based approach was the solution eventually adopted (cppyy might be different). With that said...
A small number of reviews (this thing is huge). One question: would it be possible to have the bindings per-framework, rather than a single, long list? This is also what made PyKDE4 unwieldy. IOW, each Framework should ship their (optional) bindings.
We can put the tooling in ECM so that everything is in place for all the Frameworks. (This is how the current approach works):
Tue, Sep 5
Seems you commited this but forgot to close this?
Sun, Sep 3
Thanks for the fix!
Wed, Aug 30
Patch for more docu: https://phabricator.kde.org/D7612
Aug 14 2017
Aug 13 2017
Ugh my bad ^^', I don't know what happened.
Aug 12 2017
Aug 11 2017
Main reason is having a simple way to run flatpak-builder with the proper arguments. Otherwise you have to copy-paste the command from somewhere (which could be error-prone).
One usually already has a build folder around, so the idea is you change some code, build it as usual and then you run this target to quickly test the change in flatpak.
Aug 10 2017
Ooops, sorry. I had heavily tested ... a somewhat different version of the patch :(
Aug 9 2017
Fixed with 7e7b6da
You broke all the builds
I like the initiative, +1
Oh it's gorgeous!
if no qmlplugindump
Address sitter's comments
Aug 8 2017
qmlplugindump not being found needs to be handled somehow. Other than that only minor nitpicks.