[Interest] QtQuick import question

Elvis Stansvik elvstone at gmail.com
Thu Apr 20 08:42:11 CEST 2017


Den 19 apr. 2017 11:07 fm skrev "Mitch Curtis" <mitch.curtis at 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=qt.io at qt-project.org]
On Behalf Of Elvis Stansvik
> Sent: Thursday, 13 April 2017 7:02 PM
> To: Viktor Engelmann <viktor.engelmann at qt.io>
> Cc: interest at qt-project.org Interest <interest at qt-project.org>
> Subject: Re: [Interest] QtQuick import question
>
>
>
>
> 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
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" <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
http://lists.qt-project.org/mailman/listinfo/interest
> >
> >
> > -- 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/20170420/3871812e/attachment.html>


More information about the Interest mailing list