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: [email protected] [[email protected]] on behalf of Alan Alpert [[email protected]] 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 [email protected] http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
