[Interest] QtQuick import question

Elvis Stansvik elvstone at gmail.com
Thu Apr 13 19:02:01 CEST 2017

Den 13 apr. 2017 10:13 fm skrev "Viktor Engelmann" <viktor.engelmann at qt.io>:
> The _version_ only affects which properties/methods are visible, so you
should always go for the minimal version that has all the interfaces you
> say there is a qml class foo. in version 1.0 it has method bar, in 1.1 it
also has method ham and in 1.2 method eggs.
> if you import 1.2 although you only use bar and ham, it won't run on
systems that only have version 1.1 although it could. On systems that have
1.2, you still have all the bugfixes that went into bar and ham between 1.1
and 1.2 - again, the version only affects which parts of the interface are

Right, I know how the versioning works, and I can sort of see the
need/reason for individual versioning of the Quick modules. I also agree
that it's my responsibility as a developer, packager and distributor of my
software to keep track of these things. I just wish that

a) I could have more support from the Qt docs in this, like a table mapping
Qt versions to the QML versions included in that release, and

b) A shorthand was available where I could say that "I'm targeting Qt >=
x.y.z" and be allowed to leave out the version in my QML imports (they
would default to the version included in Qt x.y.z)

All this to avoid having to repeatedly specify the version while importing,
and having to remember a bunch of 2.2, 2.4, 1.4,... numbers in my head
while coding, which is something I've never had to do with other
frameworks, no matter how modularized.


> Viktor
> p.s. I don't think that other languages "get away without having a
version". In other languages, you only push the trouble onto someone else.
So you have for example a windows 9x, a win NT, a win vista,... version of
your program and the customer must know which windows version he has (plus
you need to bundle all the non-OS libraries you use, polluting the
customers hard drive). And that approach only works for OSes that have a
very limited set of releases, which isn't the case for linux.
> On linux, it's the packagers' job to know which version of which library
has which interface. That's why you have versioned dependencies in .deb
packages for example (and that makes things a lot more difficult without
any benefit).
> On 13.04.2017 08:48, Elvis Stansvik wrote:
>> Den 13 apr. 2017 2:52 fm skrev "Jason H" <jhihn at gmx.com>:
>> >
>> >
>> >
>> > > Sent: Wednesday, April 12, 2017 at 12:05 PM
>> > > From: "VStevenP via Interest" <interest at qt-project.org>
>> > > To: interest at qt-project.org
>> > > Subject: [Interest] QtQuick import question
>> > >
>> > > When importing a QtQuick version, is it best to import the most
recent version, or the minimum version that supports the features
(properties, etc.) of the components being used?
>> >
>> > I've asked this before as well, I don't remember getting an answer. I
go with whatever the documentation for the Qt version I'm using says,
because there is no substantive table of what is in what version.
>> >
>> > I'd love to use min version, but sometimes you just don't know. Also,
there is no clear reason (that I can tell) to have a version.  I think it
would be nightmareish if Qt backeded every version of QML import that is
actually listed in my app, so I assume the version is min version.  Every
other language gets away without having a version, I wonder why Qt requires
it in the source?
>> +10, I would love if in our Quick application, we could just say "this
is the minimum Qt version we support" and avoid having to specify cryptic
versions on each QML import.
>> The lack of docs on when/in which Qt version a particular QML version of
a certain module was added doesn't help.
>> Elvis
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Interest mailing list
>> > Interest at qt-project.org
>> > http://lists.qt-project.org/mailman/listinfo/interest
>> _______________________________________________ Interest mailing list
Interest at qt-project.org
> -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower
Chaussee 13 D-12489 Berlin Viktor.Engelmann at qt.io +49 151 26784521
http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz
der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB
144331 B
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20170413/801d4e7d/attachment.html>

More information about the Interest mailing list