QtCS2024 QProperty: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Created page with "==Session Summary== ==Session Owners== ==Notes== Category:QtCS2024")
 
 
Line 5: Line 5:
==Notes==
==Notes==


QProperty was introduced in Qt6. How is it now?
* Motivation:
    * mostly for convenience, avoid messy signal handling
    * Make binding engine from QML available in C++
    * Bindings are very ergonomic in QML
    * We want to use them in Widgets too ...
    * should have also been faster than classic signal/slot, but meh
    * adds flexibility:
        * combining values in bindings rather than private slots
        * type conversions on signal handling
        * ....   
* What do we like about it?
    * Useful for reactive systems
    * Has some "interesting" private API?
    * It has seen some external contributions (compat with Q_PROPERTY)
    * QProperty might work well with new code, when keeping it in mind
   
* What went wrong?
    * Lazy evaluation didn't work, but made architecture complicated
    * Didn't succeed in making all Q_PROPERTY bindable
    * We did try, but it was too much effort
    * Duplicates KDBindings?
    * Difficult to use for interrelated properties (like with QQuickItem) 
    * Hardly anybody is maintaining it (Thiago, but no)
    * QProperty doesn't work with multiple threads at all.
        * See objectName() for hackery to resolve this
    * We'd like to offer thread safety for const getters as long as no setter is called concurrently.
        * Even that doesn't work with QProperty, though.
        * Just the const doesn't offer you that guarantee in the first time anyway.
        * QProperty introduces another source of mutability, though
    * Retrofitting it into old code is much harder
   
* Result: Not used much, even inside Qt
    * Challenging to do for non-trivial properties
    * Not usable for Qt Creator
        * would need complicated setters
        * Does not actually need bindings
    * Maybe bindings lend themselves more to the declarative paradigm of QML than procedural code.
    * Would be nice to have C++ and bindings as replacement for QML when creating UIs, without moc.
        * We're really far from that, unfortunately.
=== What should we do with it? ===
Most of the motivational points have not materialized, because we haven't been able to port
most of Qt to QProperty.
* Drop it?
    * Can't remove it from Qt6
* Leave it there, never touch it?
    * There is functionality to retrofit Q_PROPERTY with synthetic bindables.
* Improve it so that people will use it?
* Try again?
    * Ask users (Arno?) what they are using it for? Collect more use cases?
    * Have we learned anything to do better now?
    * Thread locals are problematic, is there a better way?
    * Don't try to do lazy evaluation anymore
    * Maybe find something that works better with generated code?
    * Has to integrate better with the QML engine
   
Consensus seems to gravitate to "try again".


[[Category:QtCS2024]]
[[Category:QtCS2024]]

Latest revision as of 13:17, 5 September 2024

Session Summary

Session Owners

Notes

QProperty was introduced in Qt6. How is it now?

  • Motivation:
   * mostly for convenience, avoid messy signal handling
   * Make binding engine from QML available in C++
   * Bindings are very ergonomic in QML
   * We want to use them in Widgets too ...
   * should have also been faster than classic signal/slot, but meh
   * adds flexibility:
       * combining values in bindings rather than private slots
       * type conversions on signal handling
       * ....    
  • What do we like about it?
   * Useful for reactive systems
   * Has some "interesting" private API?
   * It has seen some external contributions (compat with Q_PROPERTY)
   * QProperty might work well with new code, when keeping it in mind
   
  • What went wrong?
   * Lazy evaluation didn't work, but made architecture complicated
   * Didn't succeed in making all Q_PROPERTY bindable
   * We did try, but it was too much effort
   * Duplicates KDBindings?
   * Difficult to use for interrelated properties (like with QQuickItem)   
   * Hardly anybody is maintaining it (Thiago, but no)
   * QProperty doesn't work with multiple threads at all.
       * See objectName() for hackery to resolve this
   * We'd like to offer thread safety for const getters as long as no setter is called concurrently.
       * Even that doesn't work with QProperty, though.
       * Just the const doesn't offer you that guarantee in the first time anyway.
       * QProperty introduces another source of mutability, though
   * Retrofitting it into old code is much harder
   
  • Result: Not used much, even inside Qt
   * Challenging to do for non-trivial properties
   * Not usable for Qt Creator
       * would need complicated setters
       * Does not actually need bindings
   * Maybe bindings lend themselves more to the declarative paradigm of QML than procedural code.
   * Would be nice to have C++ and bindings as replacement for QML when creating UIs, without moc.
       * We're really far from that, unfortunately.

What should we do with it?

Most of the motivational points have not materialized, because we haven't been able to port most of Qt to QProperty.

  • Drop it?
   * Can't remove it from Qt6
  • Leave it there, never touch it?
   * There is functionality to retrofit Q_PROPERTY with synthetic bindables.
  • Improve it so that people will use it?
  • Try again?
   * Ask users (Arno?) what they are using it for? Collect more use cases?
   * Have we learned anything to do better now?
   * Thread locals are problematic, is there a better way?
   * Don't try to do lazy evaluation anymore
   * Maybe find something that works better with generated code?
   * Has to integrate better with the QML engine
   

Consensus seems to gravitate to "try again".