[Development] Platform Content Selection

[Mohamed Fawzi]

In general I think that at least for development using several directories with sensible fallbacks is the way to go:

One wants to have the possibility of overriding just some files on a platform, while still having other files coming from a default location.

Alan's solution looks very comprehensive, but maybe a little too much, I would like to have something simpler.

import paths can achieve basically what we want, so for example high_res/bla.qml will override bla.qml if the path is something like "high_res:." . 
This should work also for .js file lookup.
I.e. I would only support top level directories that are sequentially checked, and if one wants to override bla/bla/b.qml on android he should create android/bla/bla/b.qml

Imho path based selection with well known platform dependent search paths is the correct way to handle several platforms, sometime even different devices.

Thus better configurability of import paths (or resource lookups in general, possibly with a way to set them up at runtime), would be very welcome.

the .qrc only approach looks a bit too verbose to me, but something like that might well be created implicitly.


This approach does have some drawbacks:
* it can make simple qmldir usage not feasible unless "precompiled" for that platform (for example with a .qrc), because you don't know which file to pick without knowing the platoform
* in general duplicating files makes tooling more complex, as one wants to easily see if some change breaks other platforms, or something is missing, and in general it breaks some assumptions of the current code model.

This last thing is something that I am actively working on, because I think that it is something that is already used by some, and it use will only increase, no matter how the details of the lookup will be.

Fawzi
________________________________________
From: development-bounces+fawzi.mohamed=digia.com at qt-project.org [development-bounces+fawzi.mohamed=digia.com at qt-project.org] on behalf of Alan Alpert [416365416c at gmail.com]
Sent: Tuesday, January 08, 2013 6:54 PM
To: Alberto Mardegan
Cc: development
Subject: Re: [Development] Platform Content Selection

On Tue, Jan 8, 2013 at 3:17 AM, Alberto Mardegan
<mardy at 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 at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development