[Development] Runtime Platform Content Selection

[Mohamed Fawzi]

On 16 Jan 2013, at 10:28, Bache-Wiig Jens <Jens.Bache-Wiig at digia.com> wrote:

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

Yes I saw, and as it is already longer I think we can continue the rest of the discussion there
> 
> 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 agree that access to this OS information is useful, and I have nothing against it.
Still I find selector based approach better in the normal case.
The selectors could be defined in part by exactly the values returned by the functions you propose.
Dynamic selectors could be easily handled in C++ libs, by adding some selector to the
namespace of the library of the default environment.
> 
> 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.

that could be handled nicely in the current proposal by adding -highres for example to the images.
I se no reason why this "new" URL handler should not look into .qrc files.

Fawzi
> 
> Regards,
> Jens
>