[Development] Platform Content Selection

[Attila Csipa]

On 16/01/13 02:43, Alan Alpert wrote:
> I was talking about just UI. For features we have existing APIs, like
> http://doc.qt.digia.com/qtmobility/qsysteminfo.html#hasFeatureSupported
> (couldn't find the Qt 5 ex-mobility docs) which could be exposed to

Not part of even Qt Essentials, so not something you can really count 
on. And there are plenty of gray areas where UI and features can overlap 
- multimedia, sensors, etc.

> QML. Having to access sensors through Loader wrappers may not be an
> elegant proposition, but it's realistic. If you used C++ you would
> need to have a shell class or something in order to have an #ifdef
> that selects whether to create the dummy or real implementation. QML
> has Loader as it's mechanism for selecting whether to create things.

My gut feeling is that when you ask an application developer to write 
configuration specific wrappers for your cross-platform application 
framework as a standard procedure, the ideal solution might have not 
been found yet.

> This is *exactly* what I'm trying to improve with some form of static
> content selection. In that real life example, it would be an
> improvement to only have to duplicate the file(s) using
> maximumLineCount, not the whole QML UI (realistically, you'd probably
> abstract it into a component making it only one file). With some form
> of static content selection you can pick, like with ifdefs, the
> version of that particular component which will work (the version with
> the property on desktop, the version without the property on N900).
> And you only have to maintain two differing source files instead of
> two whole sets for one little property.

The problem is that this would be (sort of) OK but goes against the 
workflow and is really a painful thing to do as it feels out of place 
for several reasons:

* Maintainability. The structure can get pretty messy, especially if you 
have orthogonal selectors. Android vs iOS vs Blackberry. OK, 3 files. 
Tablet vs Phone. Umm, ok, 6 files... Landscape vs portrait... 12... Add 
multiple versions of the OS/platform you want to support... 
Combinatorial explosion. You can of course reuse *some* parts, but in 
this case reuse is not coming as a natural pattern, but something you 
force on yourself. Surely we can do better than "only two 
(*combinations) files to maintain for one little property difference" :)

* Verbosity. QML has a nice clean syntax. Now it gets littered with 
Loader boilerplate instead of one-line selectors

* Transparency. You don't see whats happening behind the Loader 
statements, (i.e. what exactly is the functional difference) without 
opening the actual file. If I would see a Text{} with an ifdef, I'd know 
what's going on, but if I just see MyText {}... You get the idea. Also, 
IDEs highlight ifdefs, which is not possible here even if you are 
checking constants

* No refactor support. You have your QtQuick 1.0 Text {} element, and 
discover the extra property... It's actually quite annoying to put it in 
a separate file/wrapper, new file, copypaste, Loader boilerplate, etc.

To sum it up - I'm not emotionally attached to a preprocessor style 
ifdef (and the ability to select source files is also a good thing), but 
*some* simpler code selection mechanism that works intra-QML would be 
more than welcome.

Best regards,
Attila