> 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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development