That guy has some great stuff. Would like to see it included. He's expressed no concern over Qt integrating his stuff.
> Sent: Friday, December 07, 2018 at 8:03 AM > From: "Fabrice Mousset | GEOCEPT GmbH" <[email protected]> > To: "'Jérôme Godbout'" <[email protected]>, "Konstantin Tokarev" > <[email protected]>, "Tomasz Siekierda" <[email protected]>, > "[email protected]" <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [Interest] Better Q_PROPERTY() ? > > Hi all, > > I have found a little project which I found very nice to use especially if > you want expose you C++ class to QML. > Take a look at this project developed by Thomas Boutroue > http://gitlab.unique-conception.org/qt-qml-tricks/qt-supermacros > and > http://gitlab.unique-conception.org/qt-qml-tricks/qt-qml-models > > Here is the link to the Lightning Talk he had at QtWS15 in Berlin. > https://www.youtube.com/watch?v=96XAaH97XYo > > I use this tools in my Qt/QML application, and it saves me so much time! > > Regards > > Fabrice > > > -----Ursprüngliche Nachricht----- > > Von: Interest <[email protected]> Im Auftrag von Jérôme > > Godbout > > Gesendet: Donnerstag, 6. Dezember 2018 18:50 > > An: Konstantin Tokarev <[email protected]>; Tomasz Siekierda > > <[email protected]>; [email protected] > > Cc: [email protected] > > Betreff: Re: [Interest] Better Q_PROPERTY() ? > > > > I agree a much simpler macro Q_PROPERTY with a type and an argument > > name would be nice addition Q_PROPERTY_RWN(proptype, arg) --> > > Q_PROPERTY(proptype arg READ arg WRITE setArg NOTIFY argChanged) > > R: for the READ part > > W: for the write part > > N: notify part > > C: constant part > > > > Would need to make all the derivated > > Q_PROPERTY_RWN > > Q_PROPERTY_RC > > Q_PROPERTY_RN > > ... > > That would stream line the naming for most value. Still can use the > > Q_PROPERTY() when something different come along. > > > > For the getter/setter function could have a simple macro but this is tricky > > if you > > use pimpl or anything else. > > This seem more per people, but not too > > > > -----Original Message----- > > From: Interest <[email protected]> On Behalf Of > > Konstantin > > Tokarev > > Sent: December 6, 2018 11:03 AM > > To: Tomasz Siekierda <[email protected]>; [email protected] > > Cc: [email protected] > > Subject: Re: [Interest] Better Q_PROPERTY() ? > > > > > > > > 05.12.2018, 23:31, "Tomasz Siekierda" <[email protected]>: > > > On Wed, 5 Dec 2018 at 18:23, Sérgio Martins via Interest > > > <[email protected]> wrote: > > >> On 2018-12-05 16:41, Jason H wrote: > > >> > Epanding to: > > >> > private: > > >> > T _N; > > >> > public: > > >> > T N() { return _N; } > > >> > void setN(T N) { if (_N != N) { M = N; emit NChanged(N); } } > > >> > signal: > > >> > void NChanged(T N); > > >> > > > >> > I know this might sound trivial but if I'm making 5 classes each > > >> with > > >> > 10 properties, that's 1500 lines of boilerplate code that I'm > > >> writing > > >> > (with code style applied). > > >> > > > >> > Is there any way to get closer to my ideal? > > >> > > >> The problem with auto-generated setters is that sometimes you'll > > >> want to > > >> modify them to do additional stuff. > > > > > > Actually, I think this is not a problem at all if we keep current > > > Q_PROPERTY. Then, if you have some special case, you'd use Q_PROPERTY > > > and manually implement getters and setters. If you have a standard > > > case (like most of the > > > time) you'd use > > > the new declaration (like Q_PROPERTY_AUTO or whatever). > > > > > > You could say it's a bit similar to new and old connect() syntax. We > > > don't need to choose one - we can have both. > > > > I'm strongly opposed to autogeneration of getters and setters, because this > > is > > far from being "standard case", except the most trivial situations, however > > it > > would be great if it was possible to avoid duplication of property name > > inside > > Q_PROPERTY for getter, setter and signal, and instead use naming convention > > (property, setProperty, propertyChanged) > > > > > > > >> If you're using QtCreator then Q_PROPERTY will be auto-completed and > > >> you > > >> just need to write the property name. > > >> > > >> Then, right click -> refactor -> "Generate missing Q_PROPERTY members". > > >> (which generates the member bodies in the header file unfortunately, > > >> https://bugreports.qt.io/browse/QTCREATORBUG-14622). > > >> > > >> Maybe we need a "Qt language server", so all other editors would > > >> benefit > > >> from such refactorings. > > >> > > >> Regards, > > >> -- > > >> Sérgio Martins | [email protected] | Senior Software Engineer > > >> Klarälvdalens Datakonsult AB, a KDAB Group company > > >> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > > >> KDAB - The Qt, C++ and OpenGL Experts > > >> _______________________________________________ > > >> Interest mailing list > > >> [email protected] > > >> https://lists.qt-project.org/listinfo/interest > > > > > > _______________________________________________ > > > Interest mailing list > > > [email protected] > > > https://lists.qt-project.org/listinfo/interest > > > > -- > > Regards, > > Konstantin > > > > _______________________________________________ > > Interest mailing list > > [email protected] > > https://lists.qt-project.org/listinfo/interest > > _______________________________________________ > > Interest mailing list > > [email protected] > > https://lists.qt-project.org/listinfo/interest > _______________________________________________ > Interest mailing list > [email protected] > https://lists.qt-project.org/listinfo/interest > _______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
