Hi, This is an interesting topic. I'm not sure that I'm convinced by anyone's arguments so far, to be honest.
More comments inline: > 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 > > There is no 'top-level' directories concept in QML. To do that on top > level directories would require the feature to be done by the > application or the platform/package. Which decreases the value of QML > as an interpreted language. > Only during development. I definitely agree that one of the major advantages of QML is that it is so fast to iteratively change stuff and test it. I do most of my iterative development on device, using vim. However, fast-cycle iterations aside, I am really not sure that there are many advantages to QML being interpreted. I think a lot of these platform-specific issues could be solved via a comprehensive review and upgrade of qmlbundle / tooling. So long as the input requirements are well-defined and well-documented (eg, specific directory naming / structure so that the tool can bundle for different platforms or form-factors appropriately), I think this sort of automation would be very beneficial. The other thing to remember is that, going forward, automated bundling and greater build-time optimization is a very good idea. Yes, we should retain QML's fast iteration cycle capability, but as we get closer to being able to realise proper AOTC of types and expressions, build-time resolution of all types, lookups, etc looks more and more desirable as a build-for-deployment time option. > > > > Imho path based selection with well known platform dependent search > paths is the correct way to handle several platforms, sometime even > different devices. > At runtime? I disagree. > > 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. > I'm really not sure it's necessary. > > the .qrc only approach looks a bit too verbose to me, but something like > that might well be created implicitly. > Implicitly? You mean, by specifying the resource search path base url at runtime? This implies having unneeded data in the qrc, relative to a different base url, which is unrelated to the current platform. > > > > 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. > > These issues are mostly resolved if it's solved at the language level. > Any such feature would work with qmldir files and the file selection > would be easily accessible via tooling. It doesn't solve the generic > platform selection problem for tooling (platform selected content > might require platform specific libraries), but it would be trivial to > hook into a simulator. I didn't understand this bit. Alan, what do you mean by "solved at the language level" - do you mean, adding an ifdef-like syntax to QML? In general, I think that these sorts of problems should be solved via tooling rather than in the language, personally. Everything needed for a particular platform or form factor should be bundled into the build for that platform or form factor, and nothing that is not needed should be included. The need to select things at run time goes away if we can bundle stuff appropriately. The issue then becomes not a run-time issue, but a build/bundle time one. During development, yes, you will have files which are "mostly" duplicates, and differ only in some platform-specific way; but most of the real problems of such duplication (files getting out of sync, etc) are solvable with tooling (eg, given that for a project, some specific directory structure must exist for the bundler, then QtCreator could automatically provide a unified per-file view, with platform-specific foldable sections, could do difference highlighting, etc). As for the qmldir issue, if we improved the module system to include "application-local installed modules" which behave like installed modules (strict type registration enforcement, etc) but are application-specific and not installed into the imports dir, but instead installed into the bundle, then this issue goes away too. Perhaps I'm misunderstanding the real problems here, or overestimating how possible it is to solve the "different branches for different platforms" via some standard specification of directory structure + appropriate tooling... Cheers, Chris.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
