07.12.2018, 19:21, "Jason H" <[email protected]>: > That guy has some great stuff. Would like to see it included. He's expressed > no concern over Qt integrating his stuff.
I'm afraid that author expressing no concern is not enough for integration of code under custom license into Qt > >> 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 -- Regards, Konstantin _______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
