Hi, I didn't have time to play with QtQuick2 yet, but looking at the code I think there are some points that should be reconsidered.
1. Naming conventions QtQuick2 items adopts an abbreviation 'SG' to prefix their class names, like QSGItem. Since SG is not a well know acronym, wouldn't be better to have a more descriptive name without abbreviating? Like, QQuickItem, QSceneItem or even QSceneGraphItem? 2. Multiple inheritance Do we still need to have QDeclarativeParserStatus as a separate class? For QtQuick1 I understand that was necessary, since the base class was a QGraphicsItem; but for QtQuick2 the base class already inherits from QObject. So in order to avoid multiple inheritance, which generally it's a good thing, QSGItem could inherit from QSGObject (a new class) which could already provide virtual methods to handle the parsing phase. That would give us a flat hierarchical tree, providing all the benefits/optimizations of not using multiple inheritance. 3. Loader component I don't know if that was fixed in QtQuick2, but since QPixmap was replaced by QImage, I think the Loader component can now implement real async loading. In QtQuick1, the async operations is somewhat fake, since it just handles the progress of the file transfer; the item is still loaded in the main thread freezing the UI when loading big components. This feature is done or addressed for QtQuick2? 4. Code duplication QtQuick2 project seems like a fork of QtQuick1, just adding new classes on top of it. It's basically duplicating some QtQuick1 classes, without placing them in a common path. That was intentional? How contributions will be handled when a patch is landed for QtQuick1, but it's also should be applied in QtQuick2? Br, Adriano _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
