[Development] Suggestion on QML portability

Donald Carr sirspudd at gmail.com
Fri Jul 20 00:56:01 CEST 2012


> Not inside this tower ;) . But I wasn't talking about comparing to the
> proliferation of an unreleased version. All the QtQuick 1 I've seen so far is
> on the dead Symbian and Maemo platforms. Even if there were many of those
> applications, how many are in continued development for both the old one and
> living platforms?

Err, as we all know, none of these platforms really took off and the
vast majority of Qt Quick usage is actually by people seeking a
general purpose productive (performant) toolkit to use on Linux based
devices. Our device eco-system never really came to full fruition, our
wide spread general Linux toolkit dominance never flagged and makes us
almost ubiquitous in certain segments like automotive and the set top
box space. This spills over into other segments where you have
hardware too crusty to run Android and licensing costs would be
prohibitive.

Next time you are cursing your inflight entertainment system, you will
probably want to start with cursing yourself.

I concur with Robin here in any case; It is really frustrating to see
such evidently co-existable maintainable code scuttled by a handful of
sed -e 's/foo/bar/g' arguments. It introduces entirely needless
burden, and will result in your groupies maintaining bash scripts
which are regularly used to remove the quills from their rumps.

An ifdef mechanism to support the co-existence of differing import
statements in otherwise identical code would also move QML out of the
glorious into the sublime.

Toodles,
Donald

-- 
-------------------------------
 °v°  Donald Carr
/(_)\ Vaguely Professional Penguin lover
 ^ ^

Cave canem, te necet lingendo
Chasing my own tail; hate to see me leave, love to watch me go
Feeding the trolls is only marginally more rewarding than feeding the
pigeons, and carries the same consequences



More information about the Development mailing list