Re: [Development] Documentation and Q_GADGET / Q_PROPERTY
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. Value types do not need signals or bindables on their properties, even when exposed to QML. Since value types can only be held in properties of object types (possibly via multiple nested value types), there is always an object property the signal of which is used to notify about changes in the value type properties. regards, Ulf -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Documentation and Q_GADGET / Q_PROPERTY
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 im Auftrag von Christian Ehrlicher via Development Gesendet: Montag, 15. Januar 2024 20:49 An: development@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@qt-project.org https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing new Qt Creator module: Qt Creator Solutions
On 5 Dec 2023, at 13:13, Volker Hilsheimer via Development wrote: On 3 Dec 2023, at 12:08, apoenitz wrote: On Sat, Dec 02, 2023 at 11:25:16AM +0100, Giuseppe D'Angelo via Development wrote: On 30/11/2023 19:39, apoenitz wrote: I propose to make this setup an official Module of Qt Creator, and herewith also nominate Jarek as Maintainer. Jarek has been pushing the idea and is the author of the biggest existing Qt Creator Solution: TaskTree[2], so for me this is the obvious choice. Comments/questions/opinions? Just wondering if we could extend the scope: do these solutions depend on QtCreator parts somehow? No, and not really planned now, but there are a few potential candidates that depend on each other (remote file and remote process access for instance). For now the idea is to have only "pure" Qt users there, but if the idea in general flies then at some time it's imaginable that "solutions" could depend on each other. If not (I've understood that TaskTree specifically doesn't), why not "just" going for a playground module? It's not feature-complete yet, and as long as there are still additions expected there are benefits to have that in-tree (e.g. atomic commit instead of submodules) that we currently believe to outweigh the benefits of a "physical" separation. But this also may change at some time. Andre’ Makes sense to start by moving code into a module under Qt Creator, and evaluate at a later point whether selected solutions could be relevant for Qt or generally be spun out into a separate repository. And +1 for Jarek as maintainer. Volker New module added now to https://wiki.qt.io/Maintainers#Qt_Creator_Maintainers, with Jarek as maintainer. Cheers, Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
