Hi, On Wed, Apr 15, 2015 at 11:49 AM, André Somers <an...@familiesomers.nl> wrote: > That's why I have been working with a RAII implementation to monitor > property changes for a while now.
This looks like an interesting idea. Another issue I often have with properties is performance related. Imagine a model that has more than one filter property. In case that two properties should be set, it does not make sense to update the model twice. Adding a special setFilters method with multiple arguments is no option if you want to use property binding in QML. So I usually have a private "update" slot and a timer that's restarted on each property invocation so that the model update will take place on the next event loop iteration. That "guard" could have a second parameter specifying a "property evaluation" slot that is guaranteed to be invoked *once* on the next event loop iteration. It might be tricky to manage the timer though, maybe setting a special custom object property "__<SLOT_NAME>_invoke_timer" storing the timer pointer could help? Or - to get rid of the expensive timer - a flag could be stored as a property controlling whether QMetaObject::invoke(this, "<SLOT_NAME>", Qt::QueuedConnection) should be called - the slot (or a c++11 lambda?) would have to reset that flag then. Thinking about this, maybe this functionality should be implemented in a separate class. Nils _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development