On Tue, Sep 27, 2011 at 11:49 PM, <[email protected]> wrote: > Hi, > > On 28/09/2011, at 3:46 AM, ext Adriano Rezende wrote: >> 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? > > "SG" is a placeholder. The plan is to rename QSGItem to QQuickItem.
Sorry, I thought that name would be the final one. QQuickItem seems much nicer. >> 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. > > What are the "benefits" of not using multiple inheritance (of an interface)? As Thiago said, it just worth it when we have two different classes using it as mixin. I can only see one advantage of using it in this way, which is to be used by other QObject-derived classes, which actually makes sense regarding code reusage, but I don't know if it worth it. >> 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? > > If only it were as simple as not using QPixmap ;) Still, we are attempting > to accomplish the same thing with QTBUG-21151. I don't know all the blocking issues, but QPixmap was a big one :). But it's good to know that it's been addressed. >> 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? > > QtQuick1 is "Done". To maintain compatibility we will probably not accept > non-crash related fixes for it. I was talking about bug fixes specifically. Since, the code is very similar, it's easy to find a bug fix that should be applied in both projects. Br, Adriano _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
