On 11/27/2014 9:13 AM, Koehne Kai wrote: >> As it is now, >> whenever I decide to add support for a new feature, I make my QML >> incompatible with older Qt versions (which is understandable) with no way of >> defining a fallback or alternative (which is not OK) regardless how trivial >> the >> new feature is. > One benefit of QML is that you can do switching between different QML files > trivially at runtime (for example by using a QFileSelector , or by using a > Loader > element ...).
This is really scratching an itch with a chainsaw... Most of the API differences are rather incremental (extra properties, convenience elements, etc). To maintain a parallel copies of the QML files with complex Loader stanzas just to support a one-liner difference is an overkill. For example the Text {} element got a linkColor property in Qt5.2... It's really pushing you the "use latest imports and ditch everyone not running the latest Qt" way. Occasionally you need to do this even though you didn't change anything in your QML (like in the case of trying to maintain a version that works on both QtQuick 1.x and QtQuick 2.x). >> Thus, the way versioning is done, combined with a lack of conditionals is >> making it really hard to maintain a QML file/app when you're not the one >> bundling the Qt libs. I still fail to grasp why this is such a no-no. If >> it's okay to >> have a >> >> #if QT_VERSION >= QT_VERSION_CHECK(5,3,0) >> >> ...why can't we have something functionally equal for QML? > To be fair, the C++ macro expander is regarded by quite a few people as > a necessary evil, not a feature new languages should aim for ... I did say *functionally* equal :) I'm not suggesting preprocessing/macro expanding is the best way to solve this problem, but QML curently has no way of getting around this except the really cumbersome Loader approach. Best regards, Attila _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest