QtCS25 - QProperty and QBindable

Session Summary

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum.

Session Owners

Ulf Hermann

Notes

- introduced with big fanfare in Qt 6

- QProperty/QBindable quite nice, but its own universe

- idea: bring QML technology to C++

- can't roll it out to our own properties

- so we didn't

- akward: both technologies co-exist in QML now

- assumption: very few people are using it (to its full extent)

- if we want to remove it in Qt 7, we need to deprecate it

- bringing that up caused outcry:

- We need an equally way to expose properties

- only used for that?

- some ideas were brought up to fix it

- for instance a mega-marco which creates "everything" for a simple property

- With such a marco, could we deprecate properties?

- what about change signals, not wanting a change signal

- need a search&replace way to move forward

- devil's advocate: it's not only about boilerplate, people also want to have the reactive properties

- no public API to have setters with custom logic; real world use cases not covered by

- would people actually use it then?

- actual real world use cases were listed, multiple C++ QProperty; one Q_PROPERTY whose getter uses them, exposed to QML

-> update one C++ property results in automatic propagation to QML

- there are already libraries out there for saving boilerplate

- remove bindable from QObject, still keep QProperty as a class, but provide a bridge to QML?

- what do we tell our users then? How would it like in the end?

- In QObject: only signals, no BINDABLE

- But internal logic can still use QProperty

- Side questions: Concept of a property in other language (in the Qt brigdes context)?

- we want to use the native property support in other languages

- signals on value types discussion / discussion about value types