[Development] Platform Content Selection

[Attila Csipa]

On 10-Jan-13 17:26, Alan Alpert wrote:
>> The Qt
>> heritage so far was, to maximize portability level, to "test for
>> features" - something sadly currenly NOT possible in an easy way in QML.
> The Qt heritage so far was desktop, where cross-device compatibility
> meant "make sure it'll still work in 640x480 resolution". Desktop

Wasn't talking about just UI. To link with dbus, you added dbus to the 
Qt configuration, not "Linux" or "Ubuntu". In an ideal world, you did 
this via pkgconfig. What I'm saying is that on the desktop it was a very 
rare case where you wouldn't have all modules, or that some modules are 
built in an incompatible way. In today's Qt world, you cannot count on 
any Qt module, component or such being present (In theory, there's Qt 
Essentials, but let's see how that plays out in terms of actual 
deployment). No way of checking whether you have QtWebkit other than 
having a Loader, put a Hello world in it and if it fails, use the layout 
that foregoes WebView usage. Ditto for MultimediaKit. Add-ons are even 
worse (having to access sensors through Loader wrappers is hardly an 
elegant proposition).

>> complete solution - users probably won't be happy people triggering tens
>> of megs of Qt downloads every now and then just because an extra
>> property has been introduced. I still think "then don't use it" is a
>> poor argument as it means "You're stuck with the first major Qt release
>> for that platform forever".
> This isn't about selecting versions of imports. You always write for
> the current version of the platform, and when the platform updates you update your app if you need new functionality. This is for the case

I'm repeating myself here, but there is no universal "current version of 
the platform" in the real, deployed world as the world doesn't 
insta-update every device of every OS when the Qt project makes a 
release, and this will be increasingly true with super-fragmented 
platforms like Android joining the show. If QtQuick 2.0 gets released to 
the Android world, you will never really be able to use features from a 
2.1 without making the choice of a) maintaining a parallel branch or b) 
ditching millions of people who did not update to whatever provides 
version 2.1. Whether it's a minor or major version bump doesn't really 
matter, as in QMLs case the file-fragmentation is immediate.

As a real life example - QtQuick 1.1 introduced the "maximumLineCount" 
property to Text {}. Symbian didn't support it till a year later, and 
the N900 never got QtQuick 1.1 officially so options were a) don't use 
the property and sacrifice visuals on N9(50) and desktop or b) maintain 
two sets of source files differing in just that property use. In this 
particular case, this is a worse compatibility proposition than C++ 
(where you either have an #ifdef, or, if it's addressable via MOC, just 
a plain "if")

Best regards,
Attila