[Development] The future of QProperty and QBindable

Volker Hilsheimer volker.hilsheimer at qt.io
Fri Mar 7 12:51:23 CET 2025


> On 7 Mar 2025, at 12:27, Ulf Hermann via Development <development at qt-project.org> wrote:
> 
> On 3/7/25 10:48, Schimkowitsch Robert wrote:
>> We widely use BINDABLE in Q_PROPERTY (>500 places) because it removes a lot of boilerplate from our C++ classes.
> > [...]
>> I have never had any issues using BINDABLE. I have avoided using them in complex situations, true, but for the simple use case I outlined, they were just a major improvement over READ/WRITE/NOTIFY.
> 
> There is "Q_PROPERTY(qreal x MEMBER m_x NOTIFY xChanged)" for the really simple cases.
> 
> With that you don't need to write any accessors at all. Not even the bindable accessor.
> 
> best,
> Ulf


Thanks for the write-up Ulf!

I think based on what we have learned by now when trying to use QBindable ourselves in Qt, the limitations and cost are indeed too severe, and the downsides too limited, to keep trying to roll it out further. And if we can’t make it a broadly used idiom in Qt itself, then the arguments for promoting it as a public API are getting pretty thin.

QBindable as an explicit type for conveniently but explicitly creating bindings, without tight moc and property-system integration, and without turning a simple assignment into something magic, seems like a plausible path forward in the long run.


Removing boilerplate from a C++ class that declares properties could be done with the help of moc, without creating bindables. I.e. a simplified Q_PROPERTY declaration that assumes some convention for getter/setter/notify-signal could be enough:

class Object : public QObject
{
    Q_OBJECT
    Q_PROPERTY(value)
public:
    // ~~~

    int value() const;
    void setValue() const;

signals:
    void valueChanged();
};

This declaration should have enough information for moc to create the necessary metaobject-data. it might require some non-trivial work on moc’s parser, I suspect, but that’s perhaps a better use of our time.


Volker



More information about the Development mailing list