In the meantime, you could create a suggestion for it so we have some way of tracking it.
From: Interest [mailto:interest-bounces+mitch.curtis=qt...@qt-project.org] On Behalf Of Mitch Curtis Sent: Thursday, 20 April 2017 9:22 AM To: Elvis Stansvik <elvst...@gmail.com> Cc: interest@qt-project.org Interest <interest@qt-project.org> Subject: Re: [Interest] QtQuick import question I don’t know. CCing JP who wrote it. From: Elvis Stansvik [mailto:elvst...@gmail.com] Sent: Thursday, 20 April 2017 8:42 AM To: Mitch Curtis <mitch.cur...@qt.io<mailto:mitch.cur...@qt.io>> Cc: interest@qt-project.org<mailto:interest@qt-project.org> Interest <interest@qt-project.org<mailto:interest@qt-project.org>>; Viktor Engelmann <viktor.engelm...@qt.io<mailto:viktor.engelm...@qt.io>> Subject: RE: [Interest] QtQuick import question Den 19 apr. 2017 11:07 fm skrev "Mitch Curtis" <mitch.cur...@qt.io<mailto:mitch.cur...@qt.io>>: > > For what it’s worth, the documentation for Qt Quick Controls 2 has (or will > have) such a table (although starting at Qt 5.7, which is when they were > released): > > > > https://doc-snapshots.qt.io/qt5-5.9/qtquickcontrols2-index.html#versions That's great to see. Do you know if the table will be extended to cover all imports (QtQuick.Window, QtQuick.Layout, ...)? Elvis > > > > From: Interest > [mailto:interest-bounces+mitch.curtis<mailto:interest-bounces%2Bmitch.curtis>=qt...@qt-project.org<mailto:qt...@qt-project.org>] > On Behalf Of Elvis Stansvik > Sent: Thursday, 13 April 2017 7:02 PM > To: Viktor Engelmann <viktor.engelm...@qt.io<mailto:viktor.engelm...@qt.io>> > Cc: interest@qt-project.org<mailto:interest@qt-project.org> Interest > <interest@qt-project.org<mailto:interest@qt-project.org>> > Subject: Re: [Interest] QtQuick import question > > > > > Den 13 apr. 2017 10:13 fm skrev "Viktor Engelmann" > <viktor.engelm...@qt.io<mailto:viktor.engelm...@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 > > use. > > > > 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 > > visible. > > 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. > > Elvis > > > > > 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" > >> <jh...@gmx.com<mailto:jh...@gmx.com>>: > >> > > >> > > >> > > >> > > Sent: Wednesday, April 12, 2017 at 12:05 PM > >> > > From: "VStevenP via Interest" > >> > > <interest@qt-project.org<mailto:interest@qt-project.org>> > >> > > To: interest@qt-project.org<mailto:interest@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@qt-project.org<mailto:Interest@qt-project.org> > >> > http://lists.qt-project.org/mailman/listinfo/interest > >> > >> > >> > >> _______________________________________________ Interest mailing list > >> Interest@qt-project.org<mailto:Interest@qt-project.org> > >> http://lists.qt-project.org/mailman/listinfo/interest > > > > > > -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee > > 13 D-12489 Berlin viktor.engelm...@qt.io<mailto:viktor.engelm...@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@qt-project.org<mailto:Interest@qt-project.org> > > http://lists.qt-project.org/mailman/listinfo/interest > >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
