From 56bc3e3a40ab694ca5e1b2887c5887e8aa05de04 Mon Sep 17 00:00:00 2001 From: Alan Alpert Date: Thu, 13 Jan 2011 15:11:33 +1000 Subject: Document level of support for QGraphicsObject properties In the context of QML, they are not officially supported as public API unless otherwise documented in QDeclarativeItem. This commit mentions that somewhere. Task-number: QTBUG-15797 Reviewed-by: Martin Jones --- doc/src/declarative/qtbinding.qdoc | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/doc/src/declarative/qtbinding.qdoc b/doc/src/declarative/qtbinding.qdoc index 4213f66..b1de3e4 100644 --- a/doc/src/declarative/qtbinding.qdoc +++ b/doc/src/declarative/qtbinding.qdoc @@ -235,6 +235,10 @@ defined by C++ classes; in fact, many of the core \l {QML Elements} are implemen C++ classes. When you create a QML object using one of these elements, you are simply creating an instance of a QObject-based C++ class and setting its properties. +To create a visual item that fits in with the Qt Quick elements, base your class off \l QDeclarativeItem instead of QObject directly. +You can then implement your own painting and functionality like any other QGraphicsObject. Note that QGraphicsItem::ItemHasNoContents is set by default on QDeclarativeItem because +it does not paint anything; you will need to clear this if your item is supposed to paint anything (as opposed to being solely for input handling or logical grouping). + For example, here is an \c ImageViewer class with an \c image URL property: \snippet doc/src/snippets/declarative/qtbinding/newelements/imageviewer.h 0 @@ -249,6 +253,11 @@ Then, any QML code loaded by your C++ application or \l{QDeclarativeExtensionPlu \snippet doc/src/snippets/declarative/qtbinding/newelements/standalone.qml 0 + +It is advised that you avoid using QGraphicsItem functionality beyond the properties documented in QDeclarativeItem. +This is because the GraphicsView backend is an implementation detail for QML, so the QtQuick items can be moved to faster backends as they become available with no change from a QML perspective. +To minimize any porting requirements for custom visual items, try to stick to the documented properties in QDeclarative item where possible as properties it inherits but doesn't document are classed as implementation details and may disappear. + Note that custom C++ types do not have to inherit from QDeclarativeItem; this is only necessary if it is a displayable item. If the item is not displayable, it can simply inherit from QObject. -- cgit v0.12