[Development] Runtime Platform Content Selection

Bache-Wiig Jens Jens.Bache-Wiig at digia.com
Wed Jan 16 10:28:42 CET 2013


On Jan 15, 2013, at 1:39 PM, 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.

I completely agree with you and I realised I already started that discussion in a separate thread: Proposal: expose the OS/platform in QML

If you have direct access to os, platform and any platform specific details in qml you can make your own decisions about which files to load or use at runtime. All within the boundaries of pure QML prototyping. It is fairly clear to me from a component development perspective that we already need this in 5.1 and I do not think we will be able to agree on any fixed directory structure that would suit the needs of every developer. I.e if I want a touch and a desktop UI, I will simply pick the right files at runtime by checking the Platform.formFactor property in my Loader. If I want to make the distinction on resolution or OS, I do that instead. But it is critical that we make these properties available to QML to enable such choices. This is a simple and pragmatic addition to QML that makes it possible to solve any immediate issues already. Optimisations, language enhancements or build system improvements can be added later.

I am certainly not against the idea of a faster/more efficient static way of choosing resources but it cannot depend on a predetermined directory ordering. I believe we should rather focus the immediate efforts on a subset of the problem, like handling multiple image resolutions within .qrc files.

Regards,
Jens




More information about the Development mailing list