[Qt5-feedback] The #include directives for Qt Essentials and Qt Add-on modules

[henry.haverinen at nokia.com]

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 henry.haverinen at nokia.com"
<henry.haverinen at nokia.com> 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
>Qt5-feedback at qt.nokia.com
>http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback