[Development] Property bindings in Qt 6

Uwe Rathmann Uwe.Rathmann at tigertal.de
Wed Oct 2 08:54:08 CEST 2019

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

> 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.


More information about the Development mailing list