On Tue, Jan 8, 2013 at 3:17 AM, Alberto Mardegan
<ma...@users.sourceforge.net> wrote:
> On 01/08/2013 02:03 AM, Alan Alpert wrote:
>> Feedback?
>>
>> It's really Qt that's cross-platform focused now, not me. I just want
>> this so that SameGame runs beautifully on BB10 :) . So while I'd
>> welcome feedback from any source, I *need* to hear it from people
>> interested in other platforms (or even just cross-platform
>> development!).
>
> As Attila wrote, platform content selection is already possible with the
> resource system (and I think it can easily be achieved with external QML
> files as well) by selecting the import paths based on the platform.
I didn't think it was easily achievable with external QML files. You
can write a qmldir file which acts like that for QML types, but that
doesn't provide the functionality for JS files, image files, or other
content (and it would have to be 'selected' for the right platform at
build time still).
Do you have an example of how this could be done? Specifically,
something that could select a different settings.js file for SameGame
without having to go through the C++ executable?
> This
> already works for me:
>
> ===============
> contains(MEEGO_EDITION,harmattan) {
> # Harmattan UI overrides
> RESOURCES += ../qml/harmattan.qrc
> DEFINES += MEEGO
> } else {
> maemo5 {
> RESOURCES += ../qml/maemo.qrc
> DEFINES += MAEMO5
> } else {
> # Desktop
> RESOURCES += ../qml/desktop.qrc
> }
> }
> ===============
I'm glad to hear it works for you. How are you generating those QRC
files? Manually? It depends on how varied your UI is per platform, but
in the case where only a few files are different it sounds like
significant overhead (less so in the most files are different case,
but that's already easily solved with different main.qml files). If
this was the solution, I think it would need to be a little more
automated.
> It seems to me that this is a problem which can/should be solved at the
> build system level.
I had the impression that it shouldn't be solved at the build system
level (even though it can be). That breaks QML as an interpreted
language, which is a nice benefit for on-device development (among
other things).
> Also, this can be used to address another concern
> you mentioned in your blog post, about the performance of the
> calculations required for resolution independence: you could have a
> preprocessor for QML files that works like this:
>
> qml-defs-processor -defs constants-bb10.js input.qml > output.qml
>
> which would load the constants-bb10.js file and substitute them in the
> input.qml file, also performing basic math operations; so, if your
> input.qml is:
>
> ===============
> Item {
> width: 4 * mm
> }
> ===============
>
> and constants-bb10.js is:
>
> ===============
> mm = 4.5
> ===============
>
> you would get the following output.qml:
>
> ===============
> Item {
> width: 18
> }
> ===============
>
> A similar tool could be produced to expand Ubuntu's units.mm(4)
> functions into the final value.
> And why not, to "compress" the QML file and remove all whitespaces :-)
We already have qmlmin that does that. You can run it on your files
for deployment, but I advise against using it during development ;) .
The reason qmlmin or a qml-defs-processor could work is that it's
purely optimization. The QML code works exactly the same with and
without it, so you can develop with the un-processed QML and then get
a speed boost for the final deployment.
--
Alan Alpert
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
