> On 7 Mar 2025, at 12:27, Ulf Hermann via Development
> <[email protected]> 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
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
