[Development] a bit big change in qtquickcontrols recently

[Bache-Wiig Jens]

On Jun 14, 2013, at 6:17 PM, Alan Alpert <416365416c at gmail.com> wrote:

> On Fri, Jun 14, 2013 at 1:17 AM, Qi Liang <Liang.Qi at digia.com> wrote:
>> Hi, all,
>> 
>> https://bugreports.qt-project.org/browse/QTBUG-31565
>> https://codereview.qt-project.org/58674
>> https://github.com/qtproject/qtquickcontrols/commit/41e13d3746c8b7b5cd550091c63fd8ab066422cf
>> 
>> The issue was raised just from yesterday, more details in the jira report.
>> 
>> My understand for the issue is:
>> QtQuickControls is the first common non-cpp qt quick module. Most of source code is QML and JS, not CPP. Before that change, they will be installed into a directory. After that change, all files are organized by the .qrc file, then in the binary.
>> 
>> Yes, it could simplify the package or deployment work very much.
>> 
>> But for me, as a developer, I can't use QML debugger to switch QML code from my own into the libraries any more. Then I think it's not an improvement in this meaning.
> 
> Can't we get the best of both worlds by having the packaging be part
> of the deployment template? I.e. it's in separate QML files, but
> there's a creator template or build step which will QRC all dependent
> QML files including selected imports?
> 
> You'll want that sort of approach anyways, because otherwise any
> QtQuick.Controls using applications will have to suffer the exact same
> drawbacks on their application code (worse debugging and maintenance
> (keeping all those qrc files up to date)).

Well at the moment the discussion is at least postponed until past the 5.1.0 release, primarily as it would anyway not make it in time for the 5.1.0 RC and in addition it causes too many issues with the version of creator that we are shipping with 5.1.0. The main issue being that it would break code completion, debugging is a secondary issue. Adding a new deployment wizard to creator is certainly high on the wish list but not quite there. Additionally a lot of people, in particular on windows are not using Creator at all. (though that is unlikely the case for qt quick development)

I believe the best solution at the moment is to put an entry in the release notes stating that deployment of qt quick controls might change in a future patch release. (i.e ideally we will already have a proper solution to this in 5.1.1 which will also ship with creator 2.8)

In Creator 2.8 we already have support for tracking files in resources, possibly solving the debugging issue and I think we can also easily solve the code completion issue (worst case by including an extra copy of the qml files with creator itself). A wizard would be great but unlikely to make it until at least 5.2 which leaves half a year of unusable deployment.

I don't think anybody is disagreeing that forcing all applications to ship a qml folder with their app containing a hundred extra files is a bit inconvenient compared with the old method of simply copying a couple of libraries next to their executable. I personally feel a bit scared at the prospect of users editing those files accidentally just by messing around in their project tree or having out of date or modified versions used together with new libraries etc. I do think we mostly agree on having them bundled but we disagree on exactly what users have to do to get there. I personally  think the default option should be to have as few user-visible files there as possible provided debugging works as expected (when they have sources installed).

Regards,
Jens