Adriano Rezende
2011-09-27 17:46:32 UTC
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
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