On 10 Jan 2013, at 01:32, Chris Adams <chris.ad...@qinetic.com.au<mailto:chris.ad...@qinetic.com.au>> wrote:
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. I think that it is an acceptable loss that not every file/ qml fragment can always live by itself, in fact in practice it is already like that. So having special "roots" in bundles could be ok if it decreases the complexity in my opinion. 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. I agree 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. I think that some runtime resource selection might be very useful, but probably bringing it up here was an error as it murkies the discussion. I will bring it up gain in a separate thread. > 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. I think that having a platform settable easily editable place where to put the sequence of lookup paths would be good. > 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? No I meant defining the possible paths at compile time, and drop the unreachable files (and maybe even compacting the structure) when deploying (which might be in a .qrc or to fs. This implies having unneeded data in the qrc, relative to a different base url, which is unrelated to the current platform. not doing what I explained above […] 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. I agree about dropping unneeded files, I disagree about having one binary per form factor 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). What I would like to have is to avoid complete duplication when possible by having common files, and platform specific directories that can override the common files. 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. I agree that we will need something like application-local modules, not sure if they need to be really different from the normal ones. 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… I agree with this statement (even I differed on the specifics ;) Fawzi
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
