[Development] Convenience Imports in QML

Bea Lam blammit at gmail.com
Wed Dec 12 02:15:20 CET 2012

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

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



More information about the Development mailing list