On 16 Jan 2013, at 10:28, Bache-Wiig Jens <[email protected]> wrote:
> > On Jan 15, 2013, at 1:39 PM, Mohamed Fawzi <[email protected]> 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 > _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
