[Development] Convenience Imports in QML

Attila Csipa qt at csipa.in.rs
Wed Dec 12 16:41:46 CET 2012


On 12/12/12 12:22, Sorvig Morten wrote:
> On Dec 11, 2012, at 4:25 AM, Alan Alpert <416365416c at gmail.com> wrote:
>> 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.

>> (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'.

> 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 .


  http://www.youtube.com/watch?v=ThWq5WN32_c


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






More information about the Development mailing list