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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
