[Development] Platform Content Selection

[Alan Alpert]

On Tue, Jan 8, 2013 at 1:45 AM, Attila Csipa <qt at csipa.in.rs> wrote:
> 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).

It's fundamentally better because it can happen at runtime. Skipping
the build process makes development and prototyping on device much
faster, especially for designers who might not be setup to build and
deploy to the device. But it's usually possible for them to transfer a
file back and forth without much difficulty. It's also more tools
friendly, because skipping the build step allows for more rapid
previewing and better introspection of the QML. I even like to edit
the files on device. This is why build stage optimizations are great
for the final deployment, but for development using an interpreted
language like QML you need to be able to skip the build step.

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

The ugliest hack is to just run the C preprocessor over your files and
pepper them with ifdefs. I know there are plenty of ways for
resourceful developers to overcome this problem, but the point of Qt
is to make it easier. You could just write a separate application per
platform without Qt but it turns out it's worth using Qt just because
it's that much easier.

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

It could get to the point of having a selector per device and it would
still be useful. I don't see a way around having lots of different
configuration data if you're trying to support lots of different
devices well. But this way you can abstract out the configuration data
and just replace that (instead of all the QML). It takes it from
zero-granularity to zero/one granularity, which is still an
improvement.

Plus if it's left generic applications can basically define the
appropriate set of selectors themselves. I'd imagine it would still be
useful if individual applications controlled that instead of
platforms, the only thing that's hard for applications to do right now
is control QML file loading like this at runtime.

--
Alan Alpert