[Development] Convenience Imports in QML

[Lincoln Ramsay]

On 13/12/12 07:12, Alan Alpert wrote:
> 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?

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