[Development] Convenience Imports in QML

[Alan Alpert]

On Tue, Dec 11, 2012 at 8:44 AM, Charley Bay <charleyb123 at gmail.com> wrote:
> Alan spaketh:
> 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
>
> <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).

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.

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

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