[Development] QML Runtime

[Alan Alpert]

For those interested in the matter, the discussion has now moved to codereview.

https://codereview.qt-project.org/#change,43539 adds the QQmlApplicationEngine
https://codereview.qt-project.org/#change,43540 adds the qml tool using it

The one thing missing from QQmlApplicationEngine is the resolution of
different paths for different platforms. I'd be interested in ideas on
how best to expose that, it might even be part of a more general
device-independent code discussion. But I think that can wait for the
next patch to QQmlApplicationEngine, it's still useful for the cases
where you know your platform/path already.

I'm aware that a lot of people are on holiday break, so these changes
won't be merged for two weeks at the earliest. Gives most people who
want to look the chance to do so.

--
Alan Alpert

On Thu, Dec 13, 2012 at 11:59 PM, Koehne Kai <Kai.Koehne at digia.com> wrote:
>> -----Original Message-----
>> From: development-bounces+kai.koehne=digia.com at qt-project.org
>> [mailto:development-bounces+kai.koehne=digia.com at qt-project.org] On
>> Behalf Of Sorvig Morten
>> Sent: Thursday, December 13, 2012 4:55 PM
>> To: development at qt-project.org
>> Subject: Re: [Development] QML Runtime
>>
>>
>> On Dec 13, 2012, at 2:06 PM, Koehne Kai <Kai.Koehne at digia.com> wrote:
>> >
>> > It's there because there are different conventions on different OS
>> > where the .qml files should be (relative to the binary). E.g. on Mac
>> > its unter .app/Contents/Resources, on QNX it's app/native, on Android
>> > it's "assets:/" ...
>>
>> This is a deployment issue we have to solve, so far using resources and qrc
>> have proved most robust in my experience.
>
> It's indeed the most robust. Actually I changed all the qtdeclarative examples just last week to use qrc:// to make them working in all scenarios (shadow build, .app folders, installed vs non-installed, launched through qmlscene). Anyhow , we didn't go for qrc:/// in the Qt Creator templates so far because
>
> - on Symbian, embedding all the resources in the binary means that they're two times in memory (that at least what Alessandro told me. Anyway, this point is mood for Qt 5).
> - It requires the developer to add every resource that he adds on the file system also to the resource file (and he only finds out at runtime if he forgot it).
> - It prevents incremental deployment/ fast turnaround cycle on embedded (you've to rebuild for every change).
> - It will obviously not work with projects not having a binary as the entry point.
>
> So all in all I still think that deploying files is the more hassle-free + future proof approach for developers, and we should rather overcome the issues in the Qt libraries + qmake to make them work without lots of template code.
>
>> Could this be set controlled by
>> QDesktopServices::DataLocation? (or a new enum value).
>
> I think DataLocation serves a different  purpose (E.g. on Mac it's the Application Support folder, which is to "be used for any data that supports an application but is not required for it to run.", while we're talking about read-only, essential data. Maybe QDesktopServices::[Application]AssetsLocation or QDesktopServices::[Application]ResourcesLocation?
>
>> >
>> > E) Using the 'right' way to show the top level widget, which also happened
>> to be OS specific: show() vs showFullScreen() vs showMaximized().
>>
>> We now have the ShowIsFullScreen style hint that platform plugin can set.
>> Then the correct app behaviour is simply to call "show()"
>
> Great :)
>
> Regards
>
> Kai
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development