[Development] Platform Content Selection

[Alan Alpert]

On Fri, Jan 11, 2013 at 2:13 AM, Attila Csipa <qt at csipa.in.rs> wrote:
> 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).

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

With UI, the Qt way was to let widgets handle the different platforms.
Which no longer works for all platforms, due to widgets not being
touch-optimized (among other things). So even C++ widget UIs need
multiple versions now, their traditional widget UI for the desktop and
a different UI (possibly made with custom widgets, or with QML) for
every non-desktop platform.

>>> 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")

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.

--
Alan Alpert