Discussion:
Convenience Imports in QML
(too old to reply)
Alan Alpert
2012-12-11 03:25:57 UTC
Permalink
I've heard complaints about all the varying version numbers used in
QML imports. I don't think we can just standardize, for example on
5.0, because the whole point of modularization is that modules don't
have to move in lockstep anymore. But I did hear an idea at Dev Days
to help confuddled users (thanks Jens!). Theoretically we could have
some helpful convenience imports the same way there are conveience
includes in C++ (like #include<QtCore>). So what do people think of
having convenience imports? These would be imports which contain zero
types, but act like a bunch of other imports. For example, there could
be a convenience import like

import Qt 5.0

Which imports all QML modules in the Qt Essentials released with 5.0.0
(except QtQuick 1). It would be the equivalent of

import QtQml 2.0
import QtQuick 2.0
import QtQuick.Window 2.0
import QtQuick.Particles 2.0
import QtAudioEngine 1.0
import QtMultimedia 5.0
import QtWebkit 3.0

Which I think is all the QML APIs, and the correct versions, in the Qt
Essential modules. Looking for QML APIs in the qt sources shows that
there's a lot of addons (like the former mobility APIs) which have QML
APIs likely to come in later. So if we had an import QtAddons 5.0 it
could look like this:

import Qt3d 2.0
import QtSensors 5.0
import QtMobility.sensors 1.3
import QtNfc 5.0
import QtBluetooth 5.0
import QtPublishSubscript 5.0
import QtBluetooth 5.0
import QtSystemInfo 5.0
import QtFeedback 5.0

Even if this is a good idea, I have no answers for the following questions:
Where will this be maintained? It practically depends on every Qt module
Who will maintain this? It needs to stay synchronized with all
modules. That's probably not going to be easy, I bet that my quick
automated attempt to find Qt 5.0 imports picked up some stuff that
shouldn't be in there (like QtQuick 1 which I manually removed, and
maybe QtMobility.sensors I don't know how that relates to QtSensors
5.0).
Who actually uses all these types at once? I hear a lot of people
annoyed by how confusing the versioning is, but I don't see many files
importing more than a couple of modules.
What's the performance impact of importing a hundred types you don't
use? It's known to have a performance cost, perhaps this convenience
import is bad enough for performance that we shouldn't allow people to
shoot themselves in the foot like this.

I imagine the best way of implementing it would be implicit imports
https://bugreports.qt-project.org/browse/QTBUG-25270 when that gets
in, if anyone wants to help with the implementation. Once that's in,
the actual implementation of a convenience import may be trivial.

--
Alan Alpert
Lorn Potter
2012-12-11 04:36:02 UTC
Permalink
Post by Alan Alpert
APIs likely to come in later. So if we had an import QtAddons 5.0 it
import Qt3d 2.0
import QtSensors 5.0
import QtMobility.sensors 1.3
FYI QtMobility.sensors has been removed.



Lorn Potter
Senior Software Engineer, QtSensors/QtSensorGestures
Thiago Macieira
2012-12-11 04:36:40 UTC
Permalink
Post by Alan Alpert
Where will this be maintained? It practically depends on every Qt module
I think that we could implement this by a special "qmldir" file that simply
tells the engine what else to import. A restricted version of this can be used
to providing aliases.
Post by Alan Alpert
Who will maintain this? It needs to stay synchronized with all
modules. That's probably not going to be easy, I bet that my quick
automated attempt to find Qt 5.0 imports picked up some stuff that
shouldn't be in there (like QtQuick 1 which I manually removed, and
maybe QtMobility.sensors I don't know how that relates to QtSensors
5.0).
This would be as much a decision as what is Essentials and what isn't.
Post by Alan Alpert
Who actually uses all these types at once? I hear a lot of people
annoyed by how confusing the versioning is, but I don't see many files
importing more than a couple of modules.
That's the question we must answer before we introduce the feature. Especiall
because of the next question.
Post by Alan Alpert
What's the performance impact of importing a hundred types you don't
use? It's known to have a performance cost, perhaps this convenience
import is bad enough for performance that we shouldn't allow people to
shoot themselves in the foot like this.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Robin Burchell
2012-12-11 09:20:12 UTC
Permalink
Hi,
Post by Alan Alpert
import Qt 5.0
The moment I read this, I immediately had some reservations ...

<snip>
Post by Alan Alpert
What's the performance impact of importing a hundred types you don't
use? It's known to have a performance cost, perhaps this convenience
import is bad enough for performance that we shouldn't allow people to
shoot themselves in the foot like this.
I know the legacy "import Qt 4.7" import had a performance impact, and
for RIM, it was enough to want to patch it out altogether. I took a
slightly less over the top approach in
b5e6ca71283f0f68b7ba6d9fe9663650751ad43e ("Register Qt 4.7 import
on-demand, instead of at startup.").

So given that the design of QML has tended to be on the side of not
encouraging design decisions that have a hefty performance impact, I'd
say that this might not be such a great idea. It's the same reason I
don't like #including an entire module instead of the specific classes
used - it's convenient and easy, but all of a sudden, preprocessing
and compilation takes a hell of a lot longer - except that this is
noticable at runtime, which impacts way more than just the developer.

$0.02 given,

Robin
Mohamed Fawzi
2012-12-11 14:29:37 UTC
Permalink
A way to work around that problem is to have completion on the imports with version number.
This is something I am currently working on in the qmljs editor of QtCreator.
In the future one could even think about suggesting the import given what you use,
but that is a more complex change.

Fawzi
________________________________________
From: development-bounces+fawzi.mohamed=***@qt-project.org [development-bounces+fawzi.mohamed=***@qt-project.org] on behalf of Alan Alpert [***@gmail.com]
Sent: Tuesday, December 11, 2012 4:25 AM
To: development
Subject: [Development] Convenience Imports in QML

I've heard complaints about all the varying version numbers used in
QML imports. I don't think we can just standardize, for example on
5.0, because the whole point of modularization is that modules don't
have to move in lockstep anymore. But I did hear an idea at Dev Days
to help confuddled users (thanks Jens!). Theoretically we could have
some helpful convenience imports the same way there are conveience
includes in C++ (like #include<QtCore>). So what do people think of
having convenience imports? These would be imports which contain zero
types, but act like a bunch of other imports. For example, there could
be a convenience import like

import Qt 5.0

Which imports all QML modules in the Qt Essentials released with 5.0.0
(except QtQuick 1). It would be the equivalent of

import QtQml 2.0
import QtQuick 2.0
import QtQuick.Window 2.0
import QtQuick.Particles 2.0
import QtAudioEngine 1.0
import QtMultimedia 5.0
import QtWebkit 3.0

Which I think is all the QML APIs, and the correct versions, in the Qt
Essential modules. Looking for QML APIs in the qt sources shows that
there's a lot of addons (like the former mobility APIs) which have QML
APIs likely to come in later. So if we had an import QtAddons 5.0 it
could look like this:

import Qt3d 2.0
import QtSensors 5.0
import QtMobility.sensors 1.3
import QtNfc 5.0
import QtBluetooth 5.0
import QtPublishSubscript 5.0
import QtBluetooth 5.0
import QtSystemInfo 5.0
import QtFeedback 5.0

Even if this is a good idea, I have no answers for the following questions:
Where will this be maintained? It practically depends on every Qt module
Who will maintain this? It needs to stay synchronized with all
modules. That's probably not going to be easy, I bet that my quick
automated attempt to find Qt 5.0 imports picked up some stuff that
shouldn't be in there (like QtQuick 1 which I manually removed, and
maybe QtMobility.sensors I don't know how that relates to QtSensors
5.0).
Who actually uses all these types at once? I hear a lot of people
annoyed by how confusing the versioning is, but I don't see many files
importing more than a couple of modules.
What's the performance impact of importing a hundred types you don't
use? It's known to have a performance cost, perhaps this convenience
import is bad enough for performance that we shouldn't allow people to
shoot themselves in the foot like this.

I imagine the best way of implementing it would be implicit imports
https://bugreports.qt-project.org/browse/QTBUG-25270 when that gets
in, if anyone wants to help with the implementation. Once that's in,
the actual implementation of a convenience import may be trivial.

--
Alan Alpert
Alan Alpert
2012-12-11 16:29:50 UTC
Permalink
Post by Mohamed Fawzi
A way to work around that problem is to have completion on the imports with version number.
This is something I am currently working on in the qmljs editor of QtCreator.
In the future one could even think about suggesting the import given what you use,
but that is a more complex change.
So QtCreator could auto-complete the import statement with a version
number based on the version of Qt currently selected to run/build the
application with? That's a good idea, and might be enough on its own
to ease the pain. I look forward to seeing that in action :) .

--
Alan Alpert
Charley Bay
2012-12-11 16:44:19 UTC
Permalink
Alan spaketh:
I've heard complaints about all the varying version numbers used in
Post by Alan Alpert
QML imports. I don't think we can just standardize, for example on
5.0, because the whole point of modularization is that modules don't
have to move in lockstep anymore. But I did hear an idea at Dev Days
to help confuddled users (thanks Jens!). Theoretically we could have
some helpful convenience imports the same way there are conveience
includes in C++ (like #include<QtCore>). So what do people think of
having convenience imports? These would be imports which contain zero
types, but act like a bunch of other imports. For example, there could
be a convenience import like
import Qt 5.0
Which imports all QML modules in the Qt Essentials released with 5.0.0
(except QtQuick 1). It would be the equivalent of
import QtQml 2.0
import QtQuick 2.0
import QtQuick.Window 2.0
import QtQuick.Particles 2.0
import QtAudioEngine 1.0
import QtMultimedia 5.0
import QtWebkit 3.0
<snip>,

This is tricky. I think all "solutions" would be imperfect, but I like the
"convenience" import-functions.

I like the idea of the "convenience-import", because my code would
"just-work" with a "known-cocktail" that is established to work together:

//FILE: MyItem.qml
import Qt 5.0
Item {
// ...my stuff always works, this file is rarely touched
}

I understand others' concerns about "load-performance". However, people
don't *have* to use the convenience imports. The issue is that much code
merely wants to use the "latest-working-cocktail" of code, or the
latest-version of a component, because they don't access the properties
directly (the local file will never break), or their access is minimal (and
it's too much work to keep touching files merely to update the import
version number).

Another option might be a "special-version-number" like "latest" that
resolves to the "latest-version":

//FILE: MyItem.qml
import QtQuick.Window latest
Item {
// ...my stuff always works, this file is rarely touched
Window {
id: window_a
}
Window {
id: window_b
}
}

--charley
Alan Alpert
2012-12-11 18:02:54 UTC
Permalink
Post by Alan Alpert
I've heard complaints about all the varying version numbers used in
Post by Alan Alpert
QML imports. I don't think we can just standardize, for example on
5.0, because the whole point of modularization is that modules don't
have to move in lockstep anymore. But I did hear an idea at Dev Days
to help confuddled users (thanks Jens!). Theoretically we could have
some helpful convenience imports the same way there are conveience
includes in C++ (like #include<QtCore>). So what do people think of
having convenience imports? These would be imports which contain zero
types, but act like a bunch of other imports. For example, there could
be a convenience import like
import Qt 5.0
Which imports all QML modules in the Qt Essentials released with 5.0.0
(except QtQuick 1). It would be the equivalent of
import QtQml 2.0
import QtQuick 2.0
import QtQuick.Window 2.0
import QtQuick.Particles 2.0
import QtAudioEngine 1.0
import QtMultimedia 5.0
import QtWebkit 3.0
<snip>,
This is tricky. I think all "solutions" would be imperfect, but I like the
"convenience" import-functions.
I like the idea of the "convenience-import", because my code would
//FILE: MyItem.qml
import Qt 5.0
Item {
// ...my stuff always works, this file is rarely touched
}
I understand others' concerns about "load-performance". However, people
don't *have* to use the convenience imports. The issue is that much code
merely wants to use the "latest-working-cocktail" of code, or the
latest-version of a component, because they don't access the properties
directly (the local file will never break), or their access is minimal (and
it's too much work to keep touching files merely to update the import
version number).
The concern about load-performance isn't about "users now have an
informed choice between faster development speed or faster runtime
speed". The concern is about people using import Qt 5.0 because it's
convenient, and then getting upset when it's too slow at runtime and
they don't realize why. We can offer power users this convenient
choice when we have a solution for ensuring average users don't
accidentally cripple themselves without knowing what they did wrong.
Post by Alan Alpert
Another option might be a "special-version-number" like "latest" that
//FILE: MyItem.qml
import QtQuick.Window latest
Item {
// ...my stuff always works, this file is rarely touched
Window {
id: window_a
}
Window {
id: window_b
}
}
You're basically asking to opt-out of the versioning system. If we
thought that was a good idea, we wouldn't require all module imports
to be versioned. Short explanation is that your deployed applications
could easily break and there's no real need to skip versioning. Long
explanation is here: http://alan.imagin-itis.net/?p=322 .

--
Alan Alpert
Charley Bay
2012-12-11 18:25:30 UTC
Permalink
Post by Alan Alpert
I understand others' concerns about "load-performance". <snip>,
The concern about load-performance isn't about "users now have an
informed choice between faster development speed or faster runtime
speed". The concern is about people using import Qt 5.0 because it's
convenient, and then getting upset when it's too slow at runtime and
they don't realize why. We can offer power users this convenient
choice when we have a solution for ensuring average users don't
accidentally cripple themselves without knowing what they did wrong.
Fair point: "Be clean up-front so you don't need to clean up later."
Post by Alan Alpert
Another option might be a "special-version-number" like "latest" that
import QtQuick.Window latest
You're basically asking to opt-out of the versioning system. If we
thought that was a good idea, we wouldn't require all module imports
to be versioned.
Well, golly, when you say it like *that*... ;-))
Post by Alan Alpert
Short explanation is that your deployed applications
could easily break and there's no real need to skip versioning. Long
explanation is here: http://alan.imagin-itis.net/?p=322 .
That link is a good read. You addressed this point (in the link above)
with:

*Q:* What if I always want the latest and greatest?
*ML:* You don’t. <snip>

I now withdraw my comment, and concede that specific-versioning-on-import
is a, "good idea".

--charley
André Pönitz
2012-12-11 21:28:00 UTC
Permalink
Post by Alan Alpert
I've heard complaints about all the varying version numbers used in
QML imports. I don't think we can just standardize, for example on
5.0, because the whole point of modularization is that modules don't
have to move in lockstep anymore. But I did hear an idea at Dev Days
to help confuddled users (thanks Jens!). Theoretically we could have
some helpful convenience imports the same way there are conveience
includes in C++ (like #include<QtCore>). So what do people think of
having convenience imports? These would be imports which contain zero
types, but act like a bunch of other imports. For example, there could
be a convenience import like
import Qt 5.0
Which imports all QML modules in the Qt Essentials released with 5.0.0
(except QtQuick 1). It would be the equivalent of
import QtQml 2.0
import QtQuick 2.0
import QtQuick.Window 2.0
import QtQuick.Particles 2.0
import QtAudioEngine 1.0
import QtMultimedia 5.0
import QtWebkit 3.0
What about something like

import QtQml from Qt 5.0
import QtQuick from Qt 5.0

or even

import QtQml from MyCustomStuff
import QtQuick from MyCustomStuff

instead?

Andre'
Lincoln Ramsay
2012-12-12 00:33:06 UTC
Permalink
Post by André Pönitz
What about something like
import QtQml from Qt 5.0
import QtQuick from Qt 5.0
+1

All the benefits of "a group of QML modules attached to a single Qt
release" without the performance problem of pulling them all in.

Then "Qt 5.0" is just some meta-thing (possibly just a qmldir file) that
lists the modules/versions it contains.

We could still allow "import Qt 5.0" but maybe not, due to the
performance problem (and a desire to avoid performance problems by default).
--
Link
André Pönitz
2012-12-12 18:57:17 UTC
Permalink
Post by Lincoln Ramsay
Post by André Pönitz
What about something like
import QtQml from Qt 5.0
import QtQuick from Qt 5.0
+1
Thanks ;-)
Post by Lincoln Ramsay
All the benefits of "a group of QML modules attached to a single Qt
release" without the performance problem of pulling them all in.
Then "Qt 5.0" is just some meta-thing (possibly just a qmldir file) that
lists the modules/versions it contains.
I actually think it's still to specfic. Upgrading from Qt 5.0 to 5.1
would need touching all source files. So

import QtQml from TheQtIUse
import QtQuick from TheQtIUse

and some one-liner somewhere that relates "TheQtIUse" with "Qt 5.0",
perhaps even through the build system should be even better.

Ande'
Giuseppe D'Angelo
2012-12-12 19:18:04 UTC
Permalink
On 12 December 2012 18:57, André Pönitz
Post by André Pönitz
I actually think it's still to specfic. Upgrading from Qt 5.0 to 5.1
would need touching all source files. So
import QtQml from TheQtIUse
import QtQuick from TheQtIUse
and some one-liner somewhere that relates "TheQtIUse" with "Qt 5.0",
perhaps even through the build system should be even better.
Am I missing something or if we would really like to do that in the
future, then we should immediately raise a P0 bug against the Qt 5.0
release and ask for the QML QtWebKit import to be renamed to
QtWebKit2?
--
Giuseppe D'Angelo
Alan Alpert
2012-12-12 21:03:38 UTC
Permalink
Post by Giuseppe D'Angelo
On 12 December 2012 18:57, André Pönitz
Post by André Pönitz
I actually think it's still to specfic. Upgrading from Qt 5.0 to 5.1
would need touching all source files. So
import QtQml from TheQtIUse
import QtQuick from TheQtIUse
and some one-liner somewhere that relates "TheQtIUse" with "Qt 5.0",
perhaps even through the build system should be even better.
Am I missing something or if we would really like to do that in the
future, then we should immediately raise a P0 bug against the Qt 5.0
release and ask for the QML QtWebKit import to be renamed to
QtWebKit2?
I think you're missing something because I cannot imagine a case where
the QtWebKit import would actually *need* to change its name. But I'm
missing the train of thought that gets you there from where the
discussion was at ;) .

--
Alan Alpert
Alan Alpert
2012-12-12 21:12:47 UTC
Permalink
On Wed, Dec 12, 2012 at 10:57 AM, André Pönitz
Post by André Pönitz
Post by Lincoln Ramsay
Post by André Pönitz
What about something like
import QtQml from Qt 5.0
import QtQuick from Qt 5.0
+1
Thanks ;-)
Post by Lincoln Ramsay
All the benefits of "a group of QML modules attached to a single Qt
release" without the performance problem of pulling them all in.
Then "Qt 5.0" is just some meta-thing (possibly just a qmldir file) that
lists the modules/versions it contains.
I actually think it's still to specfic. Upgrading from Qt 5.0 to 5.1
would need touching all source files. So
import QtQml from TheQtIUse
import QtQuick from TheQtIUse
and some one-liner somewhere that relates "TheQtIUse" with "Qt 5.0",
perhaps even through the build system should be even better.
Hmm... so you're suggesting that we tie the imports for a single
application into a single file (manageable by the build system)? That
might work...

So all the application source files would look like this:

import QtQml from MyImports
import QtQuick from MyImports

There would be one file somewhere (MyImports.qmlimports?) containing this:
import QtQml 2.0
import QtQuick 2.0
import QtQuick.Window 2.0
import QtQuick.Particles 2.0
import QtAudioEngine 1.0
import QtMultimedia 5.0
import QtWebkit 3.0

which creator would automatically generate for a new Qt 5.0.0
application and which is deployed with the application.

Then the engine resolves it entirely from deployed files, and sees (effectively)
import QtQml 2.0
import QtQuick 2.0

in each file, maintaining the existing versioned import behaviour
(just a lot easier for developers).

Is this what you're suggesting?

--
Alan Alpert
Lincoln Ramsay
2012-12-12 23:04:00 UTC
Permalink
Post by Alan Alpert
Hmm... so you're suggesting that we tie the imports for a single
application into a single file (manageable by the build system)? That
might work...
import QtQml from MyImports
import QtQuick from MyImports
import QtQml 2.0
import QtQuick 2.0
import QtQuick.Window 2.0
import QtQuick.Particles 2.0
import QtAudioEngine 1.0
import QtMultimedia 5.0
import QtWebkit 3.0
which creator would automatically generate for a new Qt 5.0.0
application and which is deployed with the application.
Then the engine resolves it entirely from deployed files, and sees (effectively)
import QtQml 2.0
import QtQuick 2.0
in each file, maintaining the existing versioned import behaviour
(just a lot easier for developers).
Is this what you're suggesting?
I can see how this would be useful to a project with lots of QML files
but it could make it problematic to move code from one project to
another (since versions may change unexpectedly). It feels like it goes
against the whole idea of versioned imports, which was to allow files to
upgrade as-needed. Then again, is it really supported to use different
versions of the same import across a single app? I know you can't use
QtQuick 1.0 and 2.0... are there other instances where it's impossible
(or a really bad idea) to use multiple versions of the same import?

Ultimately, I think this idea is somewhat orthogonal to the original
idea, which was identifying the versions of modules in a Qt release
(though you could implement the latter using the former).

eg.

Something.qml:
import QtQuick from MyImports

MyImports.qmlimports:
import QtQuick from Qt 5.0
import QtMultimedia from Qt 5.0
--
Link
Alan Alpert
2012-12-13 18:14:25 UTC
Permalink
Post by Alan Alpert
Hmm... so you're suggesting that we tie the imports for a single
application into a single file (manageable by the build system)? That
might work...
import QtQml from MyImports
import QtQuick from MyImports
import QtQml 2.0
import QtQuick 2.0
import QtQuick.Window 2.0
import QtQuick.Particles 2.0
import QtAudioEngine 1.0
import QtMultimedia 5.0
import QtWebkit 3.0
which creator would automatically generate for a new Qt 5.0.0
application and which is deployed with the application.
Then the engine resolves it entirely from deployed files, and sees (effectively)
import QtQml 2.0
import QtQuick 2.0
in each file, maintaining the existing versioned import behaviour
(just a lot easier for developers).
Is this what you're suggesting?
I can see how this would be useful to a project with lots of QML files but
it could make it problematic to move code from one project to another (since
versions may change unexpectedly). It feels like it goes against the whole
idea of versioned imports, which was to allow files to upgrade as-needed.
Then again, is it really supported to use different versions of the same
import across a single app? I know you can't use QtQuick 1.0 and 2.0... are
there other instances where it's impossible (or a really bad idea) to use
multiple versions of the same import?
It's not actually an application limitation, it's just impossible to
use QtQuick 1.x and 2.x in the same visual tree. It's theoretically
possible (but a bad idea) to use both in the same application.

It's usually a bad idea to mix major versions of the same module. With
minor versions though it is definitely very supported to use different
versions of the same import across a single app. Or even the same
file, so you could do
import QtQuick 1.0
import QtQuick 1.1 as QQ11

Item { QQ11.PinchArea {} }
Ultimately, I think this idea is somewhat orthogonal to the original idea,
which was identifying the versions of modules in a Qt release (though you
could implement the latter using the former).
eg.
import QtQuick from MyImports
import QtQuick from Qt 5.0
import QtMultimedia from Qt 5.0
Actually the original idea was just to make it easier for people to
deal with all these imports. Both ideas help with that, perhaps they
would complement each other like in your example?

--
Alan Alpert
Bea Lam
2012-12-12 01:15:20 UTC
Permalink
Post by Alan Alpert
I've heard complaints about all the varying version numbers used in
QML imports. I don't think we can just standardize, for example on
5.0, because the whole point of modularization is that modules don't
have to move in lockstep anymore. But I did hear an idea at Dev Days
to help confuddled users (thanks Jens!). Theoretically we could have
some helpful convenience imports the same way there are conveience
includes in C++ (like #include<QtCore>). So what do people think of
having convenience imports? These would be imports which contain zero
types, but act like a bunch of other imports. For example, there could
be a convenience import like
import Qt 5.0
Which imports all QML modules in the Qt Essentials released with 5.0.0
(except QtQuick 1). It would be the equivalent of
import QtQml 2.0
import QtQuick 2.0
import QtQuick.Window 2.0
import QtQuick.Particles 2.0
import QtAudioEngine 1.0
import QtMultimedia 5.0
import QtWebkit 3.0
If this means all of the type names from these modules become available
in the context of the script, then issues may arise if there are type
name clashes. If both QtAudioEngine and QtMultimedia had 'Audio' types,
then you wouldn't know which Audio type you were using, especially if
they both had similar properties and you didn't notice any problems
immediately. In this case you'd need to know which module was imported
last by the convenience 'import Qt 5.0' to confirm the source of the
type in use. (Also how would you use the Audio type from QtAudioEngine?
Does re-importing the module work?) We could try to avoid having common
type names within the modules provided by the convenience import, but
that seems contrary to the idea that they are modules independent of one
another.

(As an aside, sometimes I think we should prefer and encourage the
import form of 'import QtQuick 2.0 as Q', which would require
'Q.Rectangle {}' rather than simply 'Rectangle {}', to be more explicit
about the source of a type, and also to avoid possible name clashes. I
prefer the Python model where it's less common to encourage the 'from
module import *' form that imports everything into the local namespace.)

cheers,

Bea
Sorvig Morten
2012-12-12 10:22:59 UTC
Permalink
Post by Alan Alpert
import Qt 5.0
Which imports all QML modules in the Qt Essentials released with 5.0.0
(except QtQuick 1). It would be the equivalent of
import QtQml 2.0
import QtQuick 2.0
import QtQuick.Window 2.0
import QtQuick.Particles 2.0
import QtAudioEngine 1.0
import QtMultimedia 5.0
import QtWebkit 3.0
How about allowing imports without the version number?

import QtQml -> "give me the most recent QtQml for the current Qt install"

To explain where I'm coming from, look at Qt Creator which compiles agains Qt 4 and Qt 5 from the same branch. This is great: there is a single code base to maintain, there is no confusion on which one to get, and you don't get a combinatorial explosion of branches when you branch Qt Creator for minor releases.

During my (brief) stint as desktop components maintainer I wanted to do the same for those: "absorb" the differences between QtQuick1 and QtQuick2 and present a unified API to users. On the C++ side I had the tools I needed (#ifdefs), but there was no way around the QML imports versioning.

Morten
Attila Csipa
2012-12-12 15:41:46 UTC
Permalink
Post by Sorvig Morten
Post by Alan Alpert
import Qt 5.0
Which imports all QML modules in the Qt Essentials released with 5.0.0
If the idea is to import the essentials, then call it that: "import
QtEssentials (from Qt) 5.0" - it would look weird enough to explain why
you can't combine this "Qt5" module with, say, cascades or something
similar.
Post by Sorvig Morten
Post by Alan Alpert
(except QtQuick 1). It would be the equivalent of
import QtQml 2.0
import QtQuick 2.0
import QtQuick.Window 2.0
import QtQuick.Particles 2.0
import QtAudioEngine 1.0
import QtMultimedia 5.0
import QtWebkit 3.0
How about allowing imports without the version number?
Oh, how many times we have discussed this :)

I'll agree that the "import QtQml from Qt 5.0" is cleaner. But my
"ceterum censeo" on the QML versioning and why (the way it's implemented
- though not necessarily the way it was envisioned and described in
Alan's post) is fundamentally broken: QML import statements try to link
code to *VERSIONS* and not *API*s (hold your thoughts there for a second
and let that sink in - the difference is subtle, but important). The
insult-to-injury there is that the versions mentioned there are actually
ID strings and contain no semantics or relations. What I would like to
see a lot more is the logic applied for the good old C++ side: major
version means compatibility, minor version means features, not ad-hoc
numbering schemes. So if I do an Import QtQml 2 (or QtQml 2.*, or 2.0+)
it means I'm good with anything that provides 2.0 or a compatible API.
If you have QtQml 3.0, it means you had an API break and then it's
perfectly fine to say 'bork, import failed'.
Post by Sorvig Morten
You're basically asking to opt-out of the versioning system. If we
thought that was a good idea, we wouldn't require all module imports
to be versioned. Short explanation is that your deployed applications
could easily break and there's no real need to skip versioning. Long
explanation is here: http://alan.imagin-itis.net/?p=322 .



Short story: there is no *hard* compatibility guarantee anyway, so one
might as well let people do what they want and not pull the rug from
underneath them randomly.


Best regards,
Attila
Alan Alpert
2012-12-12 21:01:25 UTC
Permalink
Post by Attila Csipa
Post by Sorvig Morten
Post by Alan Alpert
import Qt 5.0
Which imports all QML modules in the Qt Essentials released with 5.0.0
If the idea is to import the essentials, then call it that: "import
QtEssentials (from Qt) 5.0" - it would look weird enough to explain why
you can't combine this "Qt5" module with, say, cascades or something
similar.
Post by Sorvig Morten
Post by Alan Alpert
(except QtQuick 1). It would be the equivalent of
import QtQml 2.0
import QtQuick 2.0
import QtQuick.Window 2.0
import QtQuick.Particles 2.0
import QtAudioEngine 1.0
import QtMultimedia 5.0
import QtWebkit 3.0
How about allowing imports without the version number?
Oh, how many times we have discussed this :)
I'll agree that the "import QtQml from Qt 5.0" is cleaner. But my
"ceterum censeo" on the QML versioning and why (the way it's implemented
- though not necessarily the way it was envisioned and described in
Alan's post) is fundamentally broken: QML import statements try to link
code to *VERSIONS* and not *API*s (hold your thoughts there for a second
and let that sink in - the difference is subtle, but important). The
insult-to-injury there is that the versions mentioned there are actually
ID strings and contain no semantics or relations. What I would like to
see a lot more is the logic applied for the good old C++ side: major
version means compatibility, minor version means features, not ad-hoc
numbering schemes. So if I do an Import QtQml 2 (or QtQml 2.*, or 2.0+)
it means I'm good with anything that provides 2.0 or a compatible API.
If you have QtQml 3.0, it means you had an API break and then it's
perfectly fine to say 'bork, import failed'.
That is exactly what it is supposed to be, and this is why we can't
(or at least shouldn't) just follow Qt versioning.

Major version means high-level incompatibilty, so if you import QtQml
2.0 now don't expect it to just work with QtQml 3.0. Minor version
means features, which actually means some low-level incompatibilty
because it's a different language to C++. So QtQml 2.1 is mostly the
same as QtQml 2.0, just some new features, but you still should check
that the new features don't lead to resolution conflicts before you
redeploy. So QML modules might have to jump the major/minor version
separately to Qt, and vice-versa (no new QML symbols? Don't update
your module version number just because it's Qt 5.1!).

Imagine that Qt used C instead of C++, and all functions were suddenly
just global functions in a namespace. They'd all start with qt_ to try
and avoid clashes, because any time Qt tried to add a feature that
means a new function that could conflict with the resolution of a
function from another library. This is very similar to QML's case, and
we probably could allow importing QtQuick 2.* if all our QML looked
like this:

QQuickItem {
qquickitem_width: 200
qquickitem_height: 200
}

That sort of naming is acceptable in C, and parts are done
automatically in C++ (making it way better for object oriented
programming). It's not acceptable in QML. For really fast, clean and
approachable declarative code it's better to just pick an import and
use the exact word you want.

--
Alan Alpert
Attila Csipa
2012-12-12 23:03:23 UTC
Permalink
Post by Alan Alpert
Major version means high-level incompatibilty, so if you import QtQml
2.0 now don't expect it to just work with QtQml 3.0. Minor version
means features, which actually means some low-level incompatibilty
because it's a different language to C++. So QtQml 2.1 is mostly the
same as QtQml 2.0, just some new features, but you still should check
that the new features don't lead to resolution conflicts before you
redeploy. So QML modules might have to jump the major/minor version
separately to Qt, and vice-versa (no new QML symbols? Don't update
your module version number just because it's Qt 5.1!). Imagine
Yes, I agree on the principle, but the implementation gets in the way on
many fronts.

As said, there is no semantics or relation in the version numbers. Thus
even if a new 2.1 *is* a known, verified, and perfectly compatible
superset of 2.0, the import will get rejected (as far as the import
mechanism is concerned, these versions could have been called "apple"
and "orange").

This, in fact, means: No backward *or* forward compatibility. While we
all live on the bleeding edge, this is cool. But, imagine you have Qt5
on X million devices, and Y thousand of apps that do import QtQml 2.0.
All is well. Somebody decides to change a property, bump to QtQml 2.1 or
3.0 and on the next firmware/Qt update you essentially preemptively
break *ALL* applications because *SOME* might be incompatible. The
scenario that an application is compatible with a Qt update is almost
impossible (even on Harmattan which stuck to QtQuick 1.1 from beginning
to end people still managed to occasionally burn themselves along the
way of PR1.1/1.2/1.3, N9/N950 differences, etc). Same is true for the
reverse - even if you *know* your QML works with previous version(s) of
QtQml, unless you package a separate QML for each version and do some
fallbacks, it won't work on it's own.

But there are other, smaller inconveniences, too - the "million
branches" scenario. How would Ubuntu, Debian or the others work? Now you
take package, run a build script and everything is dandy. Not so fast!
With this dependency system, you actually need to go through all the
sources and manually update everything so that you match the host system
- having some distro-specific flavor in a build directory is not enough
any more. There is no pkg-config, dynamic versioning even if you DID
verify it to work. Every version of your app is SUPER-TIGHTLY glued to
the versions provided by a particular Qt5 release. That was one of the
beauties of Qt - if it worked on 4.5, chances were it was either working
out of the box or needed just a recompile even if used with 4.8.4. With
the current versioning scheme, I'll need a separate branch for *EVERY*
single minor Qt5 release or enter QML file cloning hell. I expect git
skills improvement :)

I understand that this can be appealing because of "compatibility
guarantees", the flip side, right? Not so fast. Even simple things like
fixes can get tricky. Imagine there is a bug in 2.0. It gets fixed in
the next Qt release, but then there is no guarantee of how something
will work and you can't detect the difference from the QML side. There
will be builds with a version 2.0 that work and there will be builds
with version 2.0 that don't - so where IS that rock-solid guarantee we
are getting for the extra maintenance burden, then?

Best regards,
Attila
Alan Alpert
2012-12-13 18:10:23 UTC
Permalink
Post by Attila Csipa
Major version means high-level incompatibilty, so if you import QtQml 2.0
now don't expect it to just work with QtQml 3.0. Minor version means
features, which actually means some low-level incompatibilty because it's a
different language to C++. So QtQml 2.1 is mostly the same as QtQml 2.0,
just some new features, but you still should check that the new features
don't lead to resolution conflicts before you redeploy. So QML modules might
have to jump the major/minor version separately to Qt, and vice-versa (no
new QML symbols? Don't update your module version number just because it's
Qt 5.1!). Imagine
Yes, I agree on the principle, but the implementation gets in the way on
many fronts.
As said, there is no semantics or relation in the version numbers. Thus even
if a new 2.1 *is* a known, verified, and perfectly compatible superset of
2.0, the import will get rejected (as far as the import mechanism is
concerned, these versions could have been called "apple" and "orange").
What do you mean, rejected? The existence of 2.1 doesn't invalidate
the existence of 2.0. As they're within the same major version, 2.1
and 2.0 elements can even live happily in the same tree.
Post by Attila Csipa
This, in fact, means: No backward *or* forward compatibility. While we all
live on the bleeding edge, this is cool. But, imagine you have Qt5 on X
million devices, and Y thousand of apps that do import QtQml 2.0. All is
well. Somebody decides to change a property, bump to QtQml 2.1 or 3.0 and on
the next firmware/Qt update you essentially preemptively break *ALL*
applications because *SOME* might be incompatible. The scenario that an
application is compatible with a Qt update is almost impossible (even on
Harmattan which stuck to QtQuick 1.1 from beginning to end people still
managed to occasionally burn themselves along the way of PR1.1/1.2/1.3,
N9/N950 differences, etc). Same is true for the reverse - even if you *know*
your QML works with previous version(s) of QtQml, unless you package a
separate QML for each version and do some fallbacks, it won't work on it's
own.
Wrong. If you bump the latest QtQml to 2.1 in Qt 5.2 we still provide
QtQml 2.0, so we break *NO* applications because *SOME* might be
incompatible. For the developers they need to update to use the latest
features but guess what? That's something they'd need to do anyways to
use the latest features.This is an even stronger compatibility than Qt
has, because if you try to run a Qt 4 application against Qt 5, it
breaks. If you try to run a QtQuick 1.0 application (which somehow
magically isn't a Qt 4 application as well) against Qt 5, it still
works. Same with QtQuick 1.1. Until you actually port your application
to use the awesome new features, it just works as before - which is
the best that a deployed application can do.
Post by Attila Csipa
But there are other, smaller inconveniences, too - the "million branches"
scenario. How would Ubuntu, Debian or the others work? Now you take package,
run a build script and everything is dandy. Not so fast! With this
dependency system, you actually need to go through all the sources and
manually update everything so that you match the host system - having some
distro-specific flavor in a build directory is not enough any more. There is
no pkg-config, dynamic versioning even if you DID verify it to work. Every
version of your app is SUPER-TIGHTLY glued to the versions provided by a
particular Qt5 release. That was one of the beauties of Qt - if it worked on
4.5, chances were it was either working out of the box or needed just a
recompile even if used with 4.8.4. With the current versioning scheme, I'll
need a separate branch for *EVERY* single minor Qt5 release or enter QML
file cloning hell. I expect git skills improvement :)
Wrong again. This is actually the same as Qt. If you wanted to use a
new feature from 4.8.4 then you'd need a branch or an #ifdef because
it wouldn't work against 4.5. If you didn't use any new features, it
just needed a recompile at most (and probably shouldn't have even
needed that). Again, if you don't actually use any of the new features
in QtQuick 1.1, you just leave your Qt 4.7.1 "import QtQuick 1.0" apps
as "import QtQuick 1.0" and they'll still work fine with Qt 4.8.4.
Shouldn't even need a recompile. If you want to use features from the
new QtQuick 1.1 you'll have to update the import statements and use
the new minor version as a minimum but again this is exactly the same
as Qt.
Post by Attila Csipa
I understand that this can be appealing because of "compatibility
guarantees", the flip side, right? Not so fast. Even simple things like
fixes can get tricky. Imagine there is a bug in 2.0. It gets fixed in the
next Qt release, but then there is no guarantee of how something will work
and you can't detect the difference from the QML side. There will be builds
with a version 2.0 that work and there will be builds with version 2.0 that
don't - so where IS that rock-solid guarantee we are getting for the extra
maintenance burden, then?
There's never a perfect guarantee, but we try our best. Which is why
qtquick1 is a separate module with a copy of the old engine still
using qtscript. We could have dropped half the QtDeclarative module
and made all QtQuick 1 in Qt5 run on QML 2 but we didn't, to avoid
massive 'bug compatibility' issues. That goes a long way, and in my
opinion counts as 'rock solid' (at least as solid as talc).

--
Alan Alpert
Attila Csipa
2012-12-16 12:02:04 UTC
Permalink
Short summary for the TL;DR crowd:

I don't necessarily care how different a shiny new API implementation is
and if the fact that my application runs on it is purely coincidental
based on how I use those APIs, but not having a way to say "YES, I know
you bumped an API version, YES, I know there are potential
incompatibilities, and YES, I tested it, and YES, it still works" is
super-frustrating.
Post by Alan Alpert
Post by Attila Csipa
Yes, I agree on the principle, but the implementation gets in the way
on many fronts. As said, there is no semantics or relation in the
version numbers. Thus even if a new 2.1 *is* a known, verified, and
perfectly compatible superset of 2.0, the import will get rejected
(as far as the import mechanism is concerned, these versions could
have been called "apple" and "orange").
What do you mean, rejected? The existence of 2.1 doesn't invalidate
the existence of 2.0. As they're within the same major version, 2.1
and 2.0 elements can even live happily in the same tree.
The point is there is no implied compatibility or relationship
guarantee. Doesn't invalidate but doesn't guarantee anything either,
and, if done wrong (like the Maps API in Mobility 1.2), can be even
detrimental.
Post by Alan Alpert
Wrong. If you bump the latest QtQml to 2.1 in Qt 5.2 we still provide
QtQml 2.0, so we break *NO* applications because *SOME* might be
incompatible. For the developers they need to update to use the latest
features but guess what? That's something they'd need to do anyways to
use the latest features.This is an even stronger compatibility than Qt
has, because if you try to run a Qt 4 application against Qt 5, it
breaks. If you try to run a QtQuick 1.0 application (which somehow
magically isn't a Qt 4 application as well) against Qt 5, it still
works. Same with QtQuick 1.1. Until you actually port your application
to use the awesome new features, it just works as before - which is
the best that a deployed application can do.
No, you're looking at it from the wrong angle. As a developer, I have no
way of knowing up front what you will be bumping and what that implies
for MY application.

QtQuick, an exception as it is, still demonstrates this well. Imagine my
app using Rectangles only. I tested it with (Qt4.7, )QtQuick 1.0, 1.1
and 2.0 import statements and *verified* it works with all. All is well.
But if I use the common approach to use the lowest that works, that
opens the following potential problems - what if the particular Qt5
build I'm running on misses qtquick1 (to conserve space, incompatibility
with cascades, you name it). Bork. What if Qt5 itself drops qtquick1
from the list of supported modules? Bork on the next version. Even
though there is a *known* and *verified* import statement. This is the
difference in terms of academic discussions and the trench-engineering
realities - I don't necessarily care how different a shiny new API
implementation is and if the fact that my application runs on it is
purely coincidental based on how I use those APIs, but not having a way
to say "YES, I know you bumped an API version, YES, I know there are
incompatibilities, and YES, I tested it, and YES, it still works" is
super-frustrating.

The insult to injury is that the documentation is not too helpful wrt
versioning. For example QtQuick 1.1 introduced a number of new
properties for the Text element over QtQuick 1.0. Good luck finding out
which properties you can use in a backwards compatible fashion from
http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-text.html (which
again pushes you to play it safe and always import the latest even if
you don't necessarily need it).
Post by Alan Alpert
Wrong again. This is actually the same as Qt. If you wanted to use a
new feature from 4.8.4 then you'd need a branch or an #ifdef because
it wouldn't work against 4.5. If you didn't use any new features, it
It IS worse because there is *no* #ifdef in QML (unless you count the
unreasonably cumbersome Component {} style loading), not even for the
imports, much less the components themselves.
Post by Alan Alpert
just needed a recompile at most (and probably shouldn't have even
needed that). Again, if you don't actually use any of the new features
in QtQuick 1.1, you just leave your Qt 4.7.1 "import QtQuick 1.0" apps
as "import QtQuick 1.0" and they'll still work fine with Qt 4.8.4.
Shouldn't even need a recompile. If you want to use features from the
new QtQuick 1.1 you'll have to update the import statements and use
the new minor version as a minimum but again this is exactly the same
as Qt.
As said, QtQuick is a good exception where this is *almost* true. It's
an exception because it's the only module where the old version is still
included, technically every other module has bumped versions in a lot
less gentle way (Mobility stuff, Webkit, etc). And it's "almost true"
because there was this "import Qt 4.7" glitch* in Qt 4.7.0. Again, I
agree on the principle, but historically there was always a "good enough
reason" (business, experience, maturity, deadline, you-name-it) why the
clear QML versioning rules were implemented in a Matrix style
some-rules-can-be-broken-some-can-be-bent way which made me a lot less
enthusiastic about the general concept as implemented in Qt.

The bottom line is the QML versioning acts as a straightjacket (for a
reason, no dispute there), the pain comes from not providing any
mechanisms to compensate for the reduced mobility.

*an interesting "been there, done that" flashback that I got when the
current "import Qt 5.0" proposal was made, we already had a "import Qt
4.7" for the almost same purpose which was later renamed into QtQuick
(which technically *was* the "essentials" of the 4.7 days).

Best regards,
Attila
Alan Alpert
2012-12-16 23:20:51 UTC
Permalink
I don't necessarily care how different a shiny new API implementation is and
if the fact that my application runs on it is purely coincidental based on
how I use those APIs, but not having a way to say "YES, I know you bumped an
API version, YES, I know there are potential incompatibilities, and YES, I
tested it, and YES, it still works" is super-frustrating.
There's no way to say that because you don't need to say anything in
that case. If we bump the minor version and it still works (because
you aren't needing any of the new features) then it will still work
without you even having to alter your QML code to bump the version you
import. Would the following change help, if import Module x.y chose
the highest minor version available? So you import QtQuick 1.9, and it
will fall back to QtQuick 1.1 or 1.0, depending on which is available
on the system. This sort of functionality is what I think you're
asking for. Turns out that system is inferior to the current one,
because it has more developer effort for worse effects. You'd either
bump the minor version all the time, for the same effect as the
current system, or you'd use a large number to 'automatically' update
and risk breaking (because obviously you haven't tested against
QtQuick 1.9 yet). If you aren't using the new API then the lower minor
import continues to work, and if you are using the new API then the
lower minor import cannot work.

Note that the way the versioning system is implemented it is easy (and
strongly encouraged) to provide all minor versions of the module in
the package for that major version. So anywhere that supports QtQuick
1.1 should also support previous minor versions, like QtQuick 1.0.
That isn't strictly enforced by the engine, but should be enforced by
convention and the engine deliberately makes that case easy. As for
major versions, those are expected to be wildly different and
developers need to make a choice of major version explicitly, so not
being able to run the same code between QtQuick 1.x and QtQuick 2.x is
expected. It's like how you have to compile against Qt4 or Qt5, you
can't run the same binary against both (but because QML is an
interpreted language, the choice has to be made at runtime based on
the import statements). Eventually people will stop shipping Qt 4 and
then you'll need to provide your own if you want to keep running a Qt4
app - same with QtQuick 1. If the problem is that QtQuick 2 (or Qt 5
for that matter) looks so close that you thinks you *should* be able
to run the same code with the previous version, then you should be
disputing the choice to increment the major version instead of the
minor version.

--
Alan Alpert
Attila Csipa
2012-12-17 11:19:00 UTC
Permalink
Post by Alan Alpert
I don't necessarily care how different a shiny new API implementation is and
if the fact that my application runs on it is purely coincidental based on
how I use those APIs, but not having a way to say "YES, I know you bumped an
API version, YES, I know there are potential incompatibilities, and YES, I
tested it, and YES, it still works" is super-frustrating.
There's no way to say that because you don't need to say anything in
that case. If we bump the minor version and it still works (because
you aren't needing any of the new features) then it will still work
without you even having to alter your QML code to bump the version you
In theory, that's just fine. The real world throws two wrenches into
that train of thought:

1. I might want to use the new version if available even I don't use any
new APIs because the new version is faster, prettier, etc (case in point
- if my app works w both QtQuick 2.0 and QtQuick 1.1, I want 2.0 if
available for max performance, but am still fine running on 1.1 if need be).

2. There is no 'requirement' for many modules to be present, much less a
certain version of them. Which means the future 'compatibility' promise
I can give for my application (which runs on both) is largely guesswork
(no way of telling when "play it safe, use QtQuick 1.0" becomes "gamble
on QtQuick 1.0 presence").
Post by Alan Alpert
import. Would the following change help, if import Module x.y chose
the highest minor version available? So you import QtQuick 1.9, and it
will fall back to QtQuick 1.1 or 1.0, depending on which is available
on the system. This sort of functionality is what I think you're
asking for.
No, that would not help unless there is a set in stone guarantee that a
minor version bump implies a backward compatibility guarantee (not "best
effort", "possibility", but *guarantee*), and that a major version bump
implies major source-level incompatibilities (along the lines of "you
need to touch source even for a hello world"). Using "1.9" as syntax
would be confusing to say the least, I would go for import QtQuick 1.*
or, (even better) import QtQuick 1.0+ (so you could start from a non .0
version). All this does not solve the problem what if the major version
IS compatible enough (i.e. QtQuick 1.0 code works without change w
import QtQuick 2.0). To be able to cover that case, as a minimum, I'd
like to see

import QtQuick 2.0, QtQuick 1.0+

(listing just versions is not enough - as library/plugin names can
change, or I want to fall back to a different namespace)

And as said, this is just the first step - small version bumps are no
smaller problem than major version bumps. For example QtQuick 1.1
introduced a couple of (non-critical) extra properties for the Text {}
element. Your choices are "go for 1.0, forget the feature", "go for 1.1,
forget the 1.0 devices", or "clone QMLs or blow up the whole thing with
component loaders". All that fuss for one measly property - and we're
not even talking about compiled code. Whole components are even worse.

It's a bit scary that I while I don't ifdef as much any more, I find it
compelling to keep everything in separate git branches and solve all
this with various git magic because the QML versioning/component/import
syntax, as is, just can't cope with any (larger-scale) real life cross
multi-device/multi-Qt version deployment. Why ifdef when you can git
cherrypick/merge, right ? I already started seeing code snippets like

#ifdef platform-or-qt-version-this
viewer.setMainQmlFile(QLatin1String("qml/qtq2main.qml"));
#elif different-platform-or-qt-version
viewer.setMainQmlFile(QLatin1String("qml/qtq1main.qml"));
#else
viewer.setMainQmlFile(QLatin1String("qml/justincase.qml"));
#endif

where the three qml files differ in only - you guessed it - in the
import statement. That's *got* to be wrong.
Post by Alan Alpert
Note that the way the versioning system is implemented it is easy (and
strongly encouraged) to provide all minor versions of the module in
the package for that major version. So anywhere that supports QtQuick
1.1 should also support previous minor versions, like QtQuick 1.0.
That isn't strictly enforced by the engine, but should be enforced by
convention and the engine deliberately makes that case easy. As for
major versions, those are expected to be wildly different and
developers need to make a choice of major version explicitly, so not
being able to run the same code between QtQuick 1.x and QtQuick 2.x is
I'm repeating myself, but... The problem with this is that in the 4.x
(or, C++ days) we had this minor version guarantee, an I guess I would
expect a Qt 5.1 to be backwards compatible with Qt 5.0 on the C++ level.
This promise, IIUC, does not hold for the QML APIs - if deemed
necessary, a major version will be bumped - unfortunately there is no
way to make this easier for the *developer* (with the current versioning
approach you're taking away the ability to support a *range* of
versions, pushing people to support a *single* version even if they
*could* do more with ease).
Post by Alan Alpert
expected. It's like how you have to compile against Qt4 or Qt5, you
can't run the same binary against both (but because QML is an
interpreted language, the choice has to be made at runtime based on
the import statements). Eventually people will stop shipping Qt 4 and
then you'll need to provide your own if you want to keep running a Qt4
app - same with QtQuick 1. If the problem is that QtQuick 2 (or Qt 5
for that matter) looks so close that you thinks you *should* be able
to run the same code with the previous version, then you should be
disputing the choice to increment the major version instead of the
minor version.
I encourage you to go to qt5\examples\declarative and see how many of
the pure QML applications will continue to work if you change import
QtQuick 1.0 to 2.0. Not counting the ones using particles, surprisingly
many. I'd like to think it's a testament to a good level of
compatibility (which is desired and very welcome, helping/easing the
transition to 2.0), rather than misnaming a 1.3 into 2.0 (and given how
fragile the compatibility guarantee is there, I have no qualm of it
being called 2.0, my beef* is very strictly with the versioning logic as
implemented - it's not as bad as Flash, which made me write
tweakflashver, but sadly not that far from it, either).


Best regards,
Attila

Continue reading on narkive:
Loading...