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: [email protected] [[email protected]] on behalf of Alan Alpert [[email protected]] 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 <[email protected]> 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 [email protected] http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
