[Development] Documentation and Q_GADGET / Q_PROPERTY

Fabian Kosmale fabian.kosmale at qt.io
Mon Jan 15 21:19:04 CET 2024


Hi,

my opinion is that the clazy  warning should be treated as a false positive. In general, a Q_GADGET
can't have signals (at least not with the current design of the metaobject) system, so the warning
really doesn't make sense. So I'd say for gadgets, we should just fix clazy (and other analyzers) to not warn.

The one thing where you need NOTIFY or BINDABLE is if you want to expose a class as a type to QML
AND you want to make its instances usable in bindings; I believe that's where the warning originates
from. However,  that's not your use-case, so it shouldn't matter.

Note that adding a static meta-object (aka adding Q_GADGET) will have a small, but non-zero overhead
for binary size. On the plus side, it makes it easier to expose the class for scripting for any language
that can interact with Qt's meta-object system (including QML, where you then could use the SQL classes
inside script contexts).

In summary, I think adding the properties is worth it, and we should either fix clazy
(or just suppress the warning with a file level
// clazy:excludeall=qproperty-without-notify

Regards,
Fabian


________________________________________
Von: Development <development-bounces at qt-project.org> im Auftrag von Christian Ehrlicher via Development <development at qt-project.org>
Gesendet: Montag, 15. Januar 2024 20:49
An: development at qt-project.org
Betreff: [Development] Documentation and Q_GADGET / Q_PROPERTY

Hi,

In the sql module I've some classes which do not derive from QObject but
have a lot of setters/getters. For a nicer documentation without
duplicating information I had the idea to convert them to properties.
So I added Q_GADGET and a simple Q_PROPERTY with only a READ and WRITE
property - but this will for sure trigger a clazy warning because there
is no NOTIFY (did not tried it by myself).
Adding a signal for all those is counter-productive as you e.g. don't
want a signal emitted for every property in QSqlField created by a query...

So what's your opinion for this case? I liked the idea to compact the
documentation by using properties but not when I have to add a lot of
additional boilerplate...

See e.g. https://codereview.qt-project.org/c/qt/qtbase/+/528482

Cheers,
Christian
--
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development


More information about the Development mailing list