On 25/11/2010, at 7:25 AM, ext Charley Bay wrote: > This does raise the next question (or two): > > (1) The QML implies an "instantiation tree" of items in a parent-child > relationship. That's great, and part of what makes QML so easy to use. Is > this tree "special" in any way? For example, if I dynamically create items, > or explicitly re-parent-items, are they treated differently in any way from > the ones "hard-coded" in the QML? (I've observed strange behavior attempting > to re-parent a nested item that was hard-coded to a peer of the parent, > effectively removing it from its hard-coded parent.)
One difference is that the items created by the instantiation tree cannot be destroyed from QML (you cannot call destroy() on them the way you can for dynamically created items). I can't think of any differences in reparenting though -- do you remember what the strange behavior was that you observed? > Fun stuff! It works, and I'm happy. However, I'd feel better if one of the > Trolls would comment that I'm doing "acceptable as-designed" practice, or if > I should think about doing this differently (e.g., how to implement a C++ > layout container operating on items dynamically added/removed from QML). I'm not certain, but it's probably more of an optimization than anything else that ItemChildAddedChange is not triggered for items in the instantiation tree. If you haven't done so already, I'd suggest looking at the implementation of the QML "positioners" (Row, Column, Grid, etc) -- they layout all items (not just those added dynamically), but might give you some additional ideas for your layout container. Regards, Michael _______________________________________________ Qt-qml mailing list Qt-qml@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-qml
