[Development] Runtime Platform Content Selection

[Alan Alpert]

On Tue, Jan 15, 2013 at 4:39 AM, Mohamed Fawzi <Fawzi.Mohamed at digia.com> wrote:
> In the Platform Content Selection thread some saw runtime selection as not needed.
> I disagree, as I think it could be very useful in some occasions (high_res/low_res, different orientation,…).
> I do not believe that having a separate binary for all those things is the correct choice.
> Still the issues with runtime selection are different enough (and making the discussion on the static part unclear) that they warrant a different discussion.
>
> One could address this in another way (for example with a loader), but I think that runtime resource selection can be an attractive solution.

There are lots of other ways than Loaders. Resolution and orientation
changes can be handled with layouts, as they have been with widgets
before. The main reason static selection is so urgent, in my opinion,
is that before Qt handled those with #ifdefs. Which we don't want to
add to QML (and which Qt probably wouldn't mind using less of...). Not
to mention that #ifdefs only work for cross-platform scenarios, not
cross-device.

The big issue with runtime selection on a QML file level is that it's
impossible. Specifically, it's not possible to have a generic solution
which swaps instances between different component definitions while
maintaining the pertinent state. Some parts of the UI state needs to
travel across instances, or else the 'runtime' selection is the same
as forcibly restarting the UI* on orientation change (transferring all
parts leads to effectively no change). So in order to have runtime
selection of QML files (which are basically component definitions),
you first need to add a mechanism for the components to transfer the
correct state.

By leaving the runtime selection at the application level (while
giving them all the tools they need, like Loaders and an
orientation-aware platform component set), they manage the state
themselves and completely avoid this problem.

>
> A possible solution is to hava an environment that is basically an hash table string -> string.
> Then if any path piece is *.qmlbundle, then that string is looked up int the environment hash table and if found *.bundle is replaced with "*.bundle/"+hash.value("*.qmlbundle")

You're suggesting this be built into the bundle files? That limits the
development experience, as so far bundles are being considered a
deployment time optimization.

--
Alan Alpert

*Note that with QML you could store all the relevant state in C++
objects and reload the entire QML scene on one of these 'runtime'
changes. But you can already do that, by watching for the relevant
changes in C++. So that naive "runtime selectors" implementation
already has all it needs.