[Development] Platform Content Selection

Attila Csipa qt at csipa.in.rs
Tue Jan 8 10:45:59 CET 2013


On 08-Jan-13 02:03, Alan Alpert wrote:
> What I suggest is a path based swap-out like Plasma has, but a little
> more generic than being tied into the Plasma Package format. Here's
> the basic algorithm for swapping, where platformSelectors is an
> ordered list of selectors specified for the platform (e.g. for the
> BB10 dev alpha it might be "dev_alpha bb10 phone touch")
>
> main.qml
> Chrome.qml
> Content.qml
> settings.js
> android/Chrome.qml
> android/phone/settings.js
> android/tablet/settings.js
> phone/settings.js
> tablet/settings.js
>
> Feedback?

How is this (fundamentally) better than, say, using QRC? I had the 
feeling (as ancient as it is) qrc was already solving this problem - 
mapping a set of resources with one path structure into a given 
hierarchy (conveniently helping the packaging phase along the way).

I have seen one, even uglier hack to solve this problem - which was also 
used not only for paths, but for constants - and that was translation. 
Yes, some people apparently just do qsTr("settings"). Works in both 
QML/C++, has the option for context/numbers which lends itself very well 
for a bit of abuse.

Note that the path problem will still not solve QML's zero-granularity 
problem in cross-platform deployments - once you need to put a 
resolution or feature-dependent property in that settings file, the 
combinations explode exponentially (and thus file redundancy). Already 
for BB10 - you have 1024x600 and 1280x768, then soon 1280x720, 720x720). 
iOS has 5 different resolutions. Android is even worse. The same applies 
for any feature (HW buttons, available Qt components, etc). It feels a 
bit that the whole thing will end up with one feature per one selector 
which makes it just a bit of syntactic sugar.


Best regards,
Attila




More information about the Development mailing list