On Monday, 24 March 2025 03:06:51 Pacific Daylight Time Schimkowitsch Robert
wrote:
> Wild idea: Could I utilize C++26 reflection to generate the necessary
> getters, setters and signals in a way that moc could see? Unfortunately I
> doubt it...
We haven't begun looking into it, but we think C++2
What's the benefit of not generating it on the C++ level? I mean, I
understand you _can_ do that, but I don't quite see why you would prefer
to introduce an inconsistency like that?
QML will need a notification signal if we remove support for bindables
and Robert wants to search-replace his pr
On 2025-03-24, Ulf Hermann via Development wrote:
> Q_DEFAULT_PROPERTY(int, value)
>
> That would expand to:
The amount of custom macros like that I have removed is quite big.
Programers are lazy. They will also use that macro for readonly
properties, and constant properties.
/Sune
--
Develo
On 3/24/25 10:58, Ulf Hermann via Development wrote:
Whatever you change, please consider the upgrade path for people
using BINDABLE in many, many places.
E.g. if a new solution can be applied by regexp search & replace, or
if Qt Creator offered an "upgrade fix" via light bulb, that would be
g
> Why all the ceremony? What people probably want is:
>
> Q_DEFAULT_PROPERTY(int, value)
>
> That would expand to:
>
> Q_PROPERTY(int value READ value WRITE setValue NOTIFY valueChanged)
> public:
> int value() const { return m_value; }
> void setValue(int value)
> ...
...which
Whatever you change, please consider the upgrade path for people using BINDABLE
in many, many places.
E.g. if a new solution can be applied by regexp search & replace, or if Qt Creator
offered an "upgrade fix" via light bulb, that would be great.
We need to establish some "NOTIFY default" as p
Q_PROPERTY_FULL(int, READ int value() noexcept,
WRITE void setValue(int),
NOTIFY void valueChanged())
Why all the ceremony? What people probably want is:
Q_DEFAULT_PROPERTY(int, value)
That would expand to:
Q_PROPERTY(int value READ value WRI
Whatever you change, please consider the upgrade path for people using BINDABLE
in many, many places.
E.g. if a new solution can be applied by regexp search & replace, or if Qt
Creator offered an "upgrade fix" via light bulb, that would be great.
I still have nightmares of trying to get warning-
On Friday, 7 March 2025 03:51:23 Pacific Standard Time Volker Hilsheimer via
Development wrote:
> class Object : public QObject
> {
> Q_OBJECT
> Q_PROPERTY(value)
It would be easier to keep the current syntax with READ, WRITE, NOTIFY and
then add an extra boolean field that tells moc to
On 3/7/25 12:48, Schimkowitsch Robert wrote:
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.
That neither does the change comparison, nor will it automatically notify
That neither does the change comparison, nor will it automatically notify about
changes.
You'd have to code both manually. I don't see a major improvement. Also, I
guess this forces me to make the members public.
Not really an alternative.
You don't need to make the members public. The moc-gen
>
> 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
> {
>
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
> On 7 Mar 2025, at 12:27, Ulf Hermann via Development
> 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 hav
> 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.
>
That neither does the change comparison, nor will it automatically notify about
changes.
You'd have to code bo
;t deprecate that!
Kind regards
Robert
> -Original Message-
> From: Development On Behalf Of
> Ulf Hermann via Development
> Sent: Friday, 7 March 2025 10:15
> To: development@qt-project.org
> Subject: [Development] The future of QProperty and QBindable
>
> CAUT
Hi,
We've had a discussion [1] about QProperty and QBindable during the last
contributors' summit, but unfortunately didn't reach any conclusion.
I'll summarize the most important part of the discussion here:
"There is functionality to retrofit Q_PROPERTY with synthetic bindables."
This may
17 matches
Mail list logo
