We discussed the structure and naming of Qt5 at QtCS, but we didn't discuss the #include directive. So let's continue with this on the mailing list. (See below for a summary of the topics we covered.)
With Qt4, you can include all classes of a module with #include <QtGui> etc. Obviously you can include classes separately with #include <QNetworkAccessManager> etc. Qt Mobility doesn't seem to have the headers for including full modules -- so you cannot #include <QtSensors> for instance -- but you need to import each class separately. I wonder if there is a reason for this? For source compatibility with Qt4, I assume the existing Qt4 include directives should keep on working. What about the include directives for new modules in Qt Essentials and new Qt Add-on modules? For modules in Qt Essentials, I suppose you would just #include the class name, or the module name to get all the classes. How should this go for Qt Add-on modules? We should try to be consistent with the QML statement import QtAddOn.Foo 1.0 and the C++ namespace QtAddOn::Foo, when using the Qt Add-on Foo module. Would we have to install the Qt Add-ons so that #include <QtAddOn/Foo> would work to get all classes of the Qt Add-on Foo module? Or should it be #include <QtAddOnFoo>? Or just include individual classes? Cheers, Henry On 6/21/11 9:40 PM, "ext [email protected]" <[email protected]> wrote: > >Hello everyone, > >At QtCS, we had 4 sessions and countless hallway discussions about what we >have been calling the Qt 5 product definition. The sessions covered >general topics like the structure of Qt (the core part, add-ons etc.), >naming conventions, releasing principles, platform tier definitions, >cross-platform promise, and compatibility promise. Thanks a lot for the >very active participation and great discussions! > >During the sessions, we made conclusions about platform tiers, releasing >principles, naming conventions for add-ons, cross-platform promise, and >compatibility. However, we did not find consensus on the structure of Qt. >On one hand, we wanted to have an extremely simple structure and a clear >definition of what parts of Qt must be available on all platforms. On the >other hand, we want to have a natural home for QWidget classes, and make >sure we're sending the correct message about the existing functionalities: >they are 1st class citizens on the desktop platforms, but not necessarily >available on embedded or mobile platforms. > >We continued the talks until the very end of the summit, and during the >last hours, I believe we came up with a good proposal around "Qt >Essentials" and Qt Add-ons. Instead of detailed meeting minutes, I wrote >the results of all these sessions to this wiki page: > >http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/Qt5Produc >t >Definition > > >Please review! The whole text needs a lot of review and discussion. Do you >think that it is sending the correct messages about the direction of Qt? >Is it consistent? Is it clear and easy to understand? > >Cheers, >Henry > >_______________________________________________ >Qt5-feedback mailing list >[email protected] >http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
