[Interest] Better Q_PROPERTY() ?

[Jason H]

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" <fabrice.mousset at geocept.com>
> To: "'Jérôme Godbout'" <godboutj at amotus.ca>, "Konstantin Tokarev" <annulen at yandex.ru>, "Tomasz Siekierda" <sierdzio at gmail.com>, "sergio.martins at kdab.com" <sergio.martins at kdab.com>
> Cc: "Interest at qt-project.org" <interest at qt-project.org>
> 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 <interest-bounces at lists.qt-project.org> Im Auftrag von Jérôme
> > Godbout
> > Gesendet: Donnerstag, 6. Dezember 2018 18:50
> > An: Konstantin Tokarev <annulen at yandex.ru>; Tomasz Siekierda
> > <sierdzio at gmail.com>; sergio.martins at kdab.com
> > Cc: Interest at qt-project.org
> > 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 <interest-bounces at lists.qt-project.org> On Behalf Of Konstantin
> > Tokarev
> > Sent: December 6, 2018 11:03 AM
> > To: Tomasz Siekierda <sierdzio at gmail.com>; sergio.martins at kdab.com
> > Cc: Interest at qt-project.org
> > Subject: Re: [Interest] Better Q_PROPERTY() ?
> > 
> > 
> > 
> > 05.12.2018, 23:31, "Tomasz Siekierda" <sierdzio at gmail.com>:
> > > On Wed, 5 Dec 2018 at 18:23, Sérgio Martins via Interest
> > > <interest at lists.qt-project.org> 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 | sergio.martins at kdab.com | 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
> > >>  Interest at lists.qt-project.org
> > >>  https://lists.qt-project.org/listinfo/interest
> > >
> > > _______________________________________________
> > > Interest mailing list
> > > Interest at lists.qt-project.org
> > > https://lists.qt-project.org/listinfo/interest
> > 
> > --
> > Regards,
> > Konstantin
> > 
> > _______________________________________________
> > Interest mailing list
> > Interest at lists.qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> > _______________________________________________
> > Interest mailing list
> > Interest at lists.qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> _______________________________________________
> Interest mailing list
> Interest at lists.qt-project.org
> https://lists.qt-project.org/listinfo/interest
>