>
> charley spaketh:
> > Related question: Now that I'm in the QGraphicsItem world, which is
> *not* a
> > QObject with properties, how does QML expose attributes (since those are
> > *all* properties based)?
>
Giresh respondeth:
> QML works with properties exposed through the metaobject system
> (Q_PROPERTY). So, items have to be extend QObject at some point.
> AFAIK, QML supports properties exposed through QObject and user
> visible items must be QGraphicsObject or QDeclarativeItem (there are
> restrictions like the component's root item must be a QDeclarative
> item etc).
>
Hmmm ... good point. In theory, this means that *if* I could guarantee that
all child notification events came from QML, I *should* be able to do a C++
"cross-cast" to cast my QGraphicsItem* to a QObject*, and then pull out my
properties.
Very interesting. It will look a little weird, because QGraphicsItem has no
base class, but I think it should work? (I'll give it a try.)
My original confusion was that I didn't know if it was appropriate to
*assume* any castable type (e.g., from QGraphicsItem to a QGraphicsObject or
QDeclarativeItem). I'm still a little nervous about assuming the child
event would be from any QObject type (that means my class would be usable
fto interface from QML, and select C++ implementations) because the
QGraphicsView would otherwise manage child QGraphicsItem instances (with no
QObject in the hierarchy). However, if that's the intended design, I could
probably live with it.
> For example, the QGraphicsItem::boundingRect() is always (0,0,-1,-1), even
> > though the referenced QML component *has* width and height. Similarly,
> the
> > QGraphicsItem::opaqueArea()::boundingRect() is always (0,0,0,0). Does
> the
> > QGraphicsItem have *any* opinion about or state from attributes in the
> QML
> > element? (e.g., what attributes can I trust in the QGraphicsItem as
> being
> > those used by the QML element?)
> >
>
> QDeclarativeView builds on QGraphicsView. So,
> QGraphicsItem::boundingRect is still very much used. For a component,
> the QGraphicsItem of the component will return the (0, 0, width,
> height), so I think your testing above is probably incorrect. I think
> opaqueArea is used only for obscurity detection which is not used in
> QML and thus left unimplemented.
>
Very helpful -- opaqueArea() not used, but QGraphicsItem::boundingRect()
should reflect what was set on QML. That would be ideal -- I'll confirm
over the next day or two, but my current tests have that function as
*inconsistent* with what I've explicitly set in QML (e.g., I always see
QRectF(0,0,-1,-1) on the C++ side from the child).
> <snip>,
> > (Is the expectation that the user will merely attempt to downcast to
> > QGraphicsObject or QDeclarativeItem, handling the scenarios where it is
> not
> > that type?) For examle, I *assume* that the MouseArea will trigger child
> > notification, but it is not a QDeclarativeItem. In contrast, a
> Rectangle{}
> > or Text{} trigger child notification, and "happen to be" QDeclarativeItem
> > instances.
> >
>
> MouseArea is a QDeclarativeItem. Think of it as a transparent
> "overlay" child item that positions itself over the parent. I do not
> know why it does not trigger child notifications.
>
Right, my mistake -- MouseArea derives from Item{} (thus derived from
QDeclarativeItem). I'll double-check whether I'm getting child events from
it (I should be). In my case, I'll have to trap-and-remove that as
"special" (e.g., I don't want to treat that child like I'm treating other
children -- I'm logically implementing a layout container.)
Thanks!
--charley
_______________________________________________
Qt-qml mailing list
Qt-qml@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-qml
