Hi, Yeah, custom setters are required.
One option would be to say that such properties are implemented using the traditional property system altogether — bridging will be necessary anyway. Another option would be to implement what you described, perhaps in a more convenient way though. Simon > On 26. Sep 2019, at 17:38, Mitch Curtis <mitch.cur...@qt.io> wrote: > > >> >> -----Original Message----- >> From: Development <development-boun...@qt-project.org> On Behalf Of >> Simon Hausmann >> Sent: Thursday, 26 September 2019 5:03 PM >> To: development@qt-project.org >> Subject: [Development] Property bindings in Qt 6 >> >> Hi, >> >> Earlier this year, Olivier, Samuel, Auri and I worked on a project to re- >> evaluate how we could bring the declarative Qt Quick approach of doing user >> interfaces closer to C++, in order to allow building and running user >> interfaces >> in very memory and processor-power constrained environments. There >> were many different outcomes of this. One of them was that we figured out >> a way to compile QML binding expressions down to full C++, without any run- >> time interpretation. This required building a new way of defining properties >> and their relationships, a new property binding system. The results were so >> convincing that the plan was born to productize this for Qt 6 in multiple >> layers >> and steps. I'd like to initiate a first step in that direction by proposing >> API and >> functionality for Qt 6 and briefly outline how we see the building blocks >> apply >> to QML and Qt Quick: >> >> In QML, today, properties consist of a type, a setter function and a getter >> function, and the functions are implemented by the developer. There is also >> a change signal that needs to be emitted when the value changes. >> >> Binding expressions declared in .qml files are created behind the scenes and >> the QML engine makes sure to call the getter functions during the evaluation >> and the setter function to write the result. Through a connection to the >> change signal, bindings are automatically re-evaluated when properties >> change and the new values are passed to the setter functions. It's pretty >> magic and it works, but it requires a fair amount of indirection and side- >> loading of data structures. >> >> I would like to propose an API that replaces the setter and getter functions >> on objects with a new property template class that encapsulates the >> property value instead, and the ability to tie binding expressions to these >> properties for automatic updates. In short, it looks like this: >> >> QProperty<QString> surname("John"); >> >> QProperty<QString> lastname("Smith"); >> >> >> QProperty<QString> fullname; >> >> fullname.setBinding([&]() { return surname() + " " + lastname(); }); >> >> >> qDebug() << fullname(); // Prints "John Smith" >> >> >> surname = "Emma"; // Marks binding expression as dirty >> >> >> qDebug() << fullname(); // Re-evaluates the binding expression and prints >> "Emma Smith" >> >> >> >> >> >> You can see a work-in-progress patch for this in Gerrit at >> >> https://codereview.qt-project.org/c/qt/qtbase/+/275352 >> >> >> The basic data structure behind this is the property value itself as well as >> doubly linked lists to track dependencies between properties and binding >> expressions. Due to the encapsulation of the data itself in a class, it is >> possible to do a lazy evaluation of bindings. (Credit goes in particular to >> Olivier for the idea and first implementation in our project) >> >> >> Once this class and its documentation is complete, the next step is to build >> a >> bridge to the QML engine and the moc, so that it's possible to associate >> binding expressions in .qml files with properties declared this way. >> Similarly, >> it needs to be possible to access such properties through the meta-call, if >> they are placed inside Q_OBJECT classes. >> >> The next step is to begin applying this to the implementation of Qt Quick. >> Some of which may require shims for the public Qt Quick API (to keep it >> Q_PROPERTY based), and for the private Qt Quick types the idea would be to >> start using QProperty. >> >> Finally, once all the pieces are in place, we hope to extend the qml tooling >> to >> compile the binding expressions in .qml files to C++ that uses this more >> light- >> weight property system whenever possible. Ulf has been working towards >> this from the QML engine direction (see the recent email about moc and >> meta-type extraction) and Fabian has been working on the QML linter as a >> starting point towards a compilation model for QML. >> >> >> This is our rough plan of how we'd like to address one aspect of QML and Qt >> Quick today. We are looking forward to any feedback and questions to help >> us review and refine this design. > > I think you guys did an awesome job with it from what I've seen. :) > > In my experience with a similar system, one drawback is the lack of ability > to implement custom setters. For example, I often find that I need to > validate some input to a setter: > > https://code.qt.io/cgit/qt/qtquickcontrols2.git/tree/src/quicktemplates2/qquickslider.cpp#n355 > > In the end the solution was to use "dirty events" (i.e. derive from a certain > type, implement operator() and pass a pointer the property in its > constructor) as a way of reacting to the changes after they were made, but > this is not ideal. > > Will custom setters be possible? > >> >> Simon _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development