[Development] Convenience Imports in QML

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

Fawzi
________________________________________
From: development-bounces+fawzi.mohamed=digia.com at qt-project.org [development-bounces+fawzi.mohamed=digia.com at qt-project.org] on behalf of Alan Alpert [416365416c at 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
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development