[Development] Platform Content Selection

[Alan Alpert]

On Wed, Jan 9, 2013 at 4:32 PM, Chris Adams <chris.adams at 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.
>
>
> 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.

I completely agree, but fast-cycle iterations are very valuable. The
ideal is to have the development benefits of an interpreted language
during development, and the performance optimizations of chucking that
'interpreted' out for the final release.

>> >
>> > 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?

I mean something that's available to all users of QML at run-time
(regardless of whether they use QtQuick or not). That could be an
ifdef-like syntax, or it could be elements in the QtQml module, but I
don't think either of those implementations would be able to smoothly
integrate cross-device functionality.

> In general, I think that these sorts of problems should be solved via
> tooling rather than in the language, personally.

If that can be done at runtime in the same way for all devices, sure.
I don't think that's possible, because all devices means across all
platforms and then we need to take into account the different
packaging requirements for all platforms.

That said, if we can't find a good generic solution for the language
then second best would be to provide support so that individual
platforms can implement a good solution. We lose the cross-platform
nature of QML (such as it is) in this case, but there's a better
cross-device solution possible. This is spurred on by looking at the
limitations of the plasmapackage approach, due to it being added on
external to the engine - they'd have an easy time implementing a
powerful selection mechanism if they just shipped their own customized
Qt ;) .

> 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).

This sounds just like what I proposed, plus a bundle time
optimization? You need the run-time selection for development (using a
directory hierarchy same as the bundler) and it can be optimized for
deployment.

--
Alan Alpert