Hi Chris,
should individual items have to know/track this ...
Well, anchoring is also based on size changes, but uses a different type of notification -> item change listeners. Not sure why the authors decided to introduce yet another type of notification - instead of using event + event filtering - but it is obvious, that the way how property bindings are processed is irrelevant, when not being involved. Maybe a side note on anchoring: with AutoLayout ( IOS ) and ConstraintLayout ( Android ) there seems to be a trend to Cassowary ( http://overconstrained.io ) based layouts for declarative systems. QGraphicsAnchorLayout is also based on the Simplex algo, while Qt/Quick anchoring with its property-pingpong approach - well, judge yourself.
Maybe I'm misunderstanding again, but that's what the binding is supposed to implement (a change to a dependency marks the binding as dirty but doesn't trigger its evaluation until the property which owns the binding is accessed, at which point the binding is evaluated).
Technically it is possible to do a lazy calculation of the implicit size by overloading QQuickItemPrivate::getImplicitWidth/Height. But this is only used by Text/TextInput/TextEdit and is not part of the public API. Not to mention, that QML code will never be able to make use of it. Also the implicit size of longish texts is usually irrelevant as in most situations the layout needs a height-for-width value. IIRC Qt/Quick does not even has a concept for how to deal with this type of constraints. Furthermore: layout calculations have to be done in top down order - the container needs to have its final geometry first. With my approach of doing things in updatePolish it means, that the to-be-polished list has to be ordered and to do so items need know their item-tree depth to allow fast insertions. Stuff like this is what IMHO needs to be done to substantially improve the layout system of Qt/Quick and the maintainers of Qt/Quick Core and Controls need to become active. Kudos to all these micro optimizations in the runtime environment, but they can't compensate systemic design problems. Uwe _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
