[Development] Platform Content Selection

[Alan Alpert]

On Thu, Jan 10, 2013 at 4:16 AM, Attila Csipa <qt at csipa.in.rs> wrote:
> On 10-Jan-13 04:25, Alan Alpert wrote:
>> So I'll try to replace "cross-platform" now with "cross-device".
> \> but I still prefer run-time). Android has the same problem, I have a
>> lot of apps on my Nexus 7 which either literally or metaphorically do
>> not work on that device. There are also apps that just have an ugly
>> black border thanks to the auto-compatibility layer. As a convenience
>> GUI toolkit, I think Qt should have some way to help application
>> developers with this problem. I'm just focused on QML because I'm
>> always focused on QML :) .
>
> Have it clear if the selection is features, platform or devices, because
> if you have a vague mix, the results will be weird. "BB10" means very
> little in this context - I know you will adjust margins, but you will
> also have to leave out WebView elements, QtMultimediaKit, etc, and
> that's an adaptation that's not reusable if it all gets stuck under a
> "BB10" directory/tag (for example iOS might also not have QtWebkit). To
> me a "BB10" tag sounds more like "cascades" because that's one thing
> that has 1:1 relation with the platform. Devices tags are also a weird
> proposition (so do we now get a "2013 13" Macbook Air" tag? or is this
> mobile-only? do we mash all 10 variants of SGS3 into one?).

Sadly, this is not clear. My initial thought was platforms because
that's the distinction you need in order to vary platform component
sets. But plasma's approach is form-factor based, so you can vary
design across different form factors (different devices) on the same
platform. So unless anyone has a better idea, my thought was to make
the implementation agnostic to this so that we can let the tags evolve
somewhat.

> 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
devices are all very similar, even touch-screen computers always have
a mouse and keyboard as well (consequently, their touch interface was
ignored for the longest time).  Add to this that full-screen
applications are not the norm, and then you use resizeable layouts
more and don't optimize for a particular exact window size. A specific
mobile device selects your exact window size, your selection of user
inputs, and a different UI framework (one that can't be hidden away
like QtWidgets did). The Qt heritage so far solved the problems of its
era. Now there are new problems.

> The other problem with "BB10" or "Android" style tags is "which
> version"? BB10 might put in features from upstream Qt later, but how
> would you know if your selected QML was meant for BB10 10.0 or 10.1, ICS
> or JB Android (back to the imports story)? There are and will be cases
> where the same binary needs to run on different Qt setups. Device
> firmware upgrade cycles are not guaranteed, and while some platforms
> might do ministro/smartinstaller-style upgrades, it's still not a
> 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
where the current versions of the platforms across all the devices are
known, but you're deploying to multiple devices and/or platforms.

--
Alan Alpert