Discussion:
Better Q_PROPERTY() ?
(too old to reply)
Jason H
2018-12-05 16:41:12 UTC
Permalink
I've been doing a lot of Q_PROPERTY stuff again, and I waste too much time writing boiler plate code. Last time, I was reminded of the MEMBER modifier, which is what I thought I wanted. But after having worked with it some more, it's not what I want.

Given:
Q_PROPERTY (qreal scale READ scale WRITE setScale NOTIFY scaleChanged) // What I end up writing
Q_PROPERTY (qreal scale MEMBER _scale NOTIFY) // What I want to write

I want the member form to also declare/implement:
public:
qreal scale() { return _scale; }
void setScale(qreal scale) { if (scale != scale) { _scale = scale; emit scaleChanged(scale); } }
signal:
void scaleChanged(qreal scale);

Where T=type, N=name M=member
public:
T N() { return M; }
void setN(T N) { if (M != N) { M = N; emit NChanged(N); } }
signal:
void NChanged(T N);

I'm trying to think of how to do this, and this seems doable:

class X {

...
INCLUDE_AUTOMOC_DECLARATIONS
};

Where
INCLUDE_AUTOMOC_DECLARATIONS expands to:
#include "filename_X_automoc.h"

Where MOC has written the declarations. Similarly, there can be one for implementations as well.

Ideally though, all I should need to write:
Q_PROPERTY (qreal scale NOTIFY)

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?
Tomasz Olszak
2018-12-05 16:50:35 UTC
Permalink
I would love to see that too!!!

Just remember about qFuzzy* for real values :)
Post by Jason H
I've been doing a lot of Q_PROPERTY stuff again, and I waste too much time
writing boiler plate code. Last time, I was reminded of the MEMBER
modifier, which is what I thought I wanted. But after having worked with it
some more, it's not what I want.
Q_PROPERTY (qreal scale READ scale WRITE setScale NOTIFY scaleChanged) //
What I end up writing
Q_PROPERTY (qreal scale MEMBER _scale NOTIFY) // What I want to write
qreal scale() { return _scale; }
void setScale(qreal scale) { if (scale != scale) { _scale = scale; emit
scaleChanged(scale); } }
void scaleChanged(qreal scale);
Where T=type, N=name M=member
T N() { return M; }
void setN(T N) { if (M != N) { M = N; emit NChanged(N); } }
void NChanged(T N);
class X {
...
INCLUDE_AUTOMOC_DECLARATIONS
};
Where
#include "filename_X_automoc.h"
Where MOC has written the declarations. Similarly, there can be one for
implementations as well.
Q_PROPERTY (qreal scale NOTIFY)
T _N;
T N() { return _N; }
void setN(T N) { if (_N != N) { M = N; emit NChanged(N); } }
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?
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
Jason H
2018-12-06 17:18:29 UTC
Permalink
_______________________________________________
Interest mailing list
***@lists.qt-project.org
https://lists.qt-project.org/listinfo/interest
Vlad Stelmahovsky
2018-12-05 17:14:09 UTC
Permalink
use QtCreator, so you can autogenerate most of the code there
Post by Jason H
I've been doing a lot of Q_PROPERTY stuff again, and I waste too much time writing boiler plate code. Last time, I was reminded of the MEMBER modifier, which is what I thought I wanted. But after having worked with it some more, it's not what I want.
Q_PROPERTY (qreal scale READ scale WRITE setScale NOTIFY scaleChanged) // What I end up writing
Q_PROPERTY (qreal scale MEMBER _scale NOTIFY) // What I want to write
qreal scale() { return _scale; }
void setScale(qreal scale) { if (scale != scale) { _scale = scale; emit scaleChanged(scale); } }
void scaleChanged(qreal scale);
Where T=type, N=name M=member
T N() { return M; }
void setN(T N) { if (M != N) { M = N; emit NChanged(N); } }
void NChanged(T N);
class X {
...
INCLUDE_AUTOMOC_DECLARATIONS
};
Where
#include "filename_X_automoc.h"
Where MOC has written the declarations. Similarly, there can be one for implementations as well.
Q_PROPERTY (qreal scale NOTIFY)
T _N;
T N() { return _N; }
void setN(T N) { if (_N != N) { M = N; emit NChanged(N); } }
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?
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
Jean-Michaël Celerier
2018-12-05 18:29:27 UTC
Permalink
If it's Q_PROPERTY grievance time, can we add static, compile-time
reflection of the property's attributes ?

here's the macro I've quickly cobbled for myself, if it can be useful to
anyone else :
https://github.com/jcelerier/verdigris/blob/master/src/wobjectdefs.h#L918 ;
it has been extremely useful for me to generate a lot of UI stuff easily as
well as implementing a generic command pattern (that doesn't hide
everything behind a QVariant).

Best,
Jean-Michaël


-------
Jean-Michaël Celerier
http://www.jcelerier.name
Post by Vlad Stelmahovsky
use QtCreator, so you can autogenerate most of the code there
Post by Jason H
I've been doing a lot of Q_PROPERTY stuff again, and I waste too much
time writing boiler plate code. Last time, I was reminded of the MEMBER
modifier, which is what I thought I wanted. But after having worked with it
some more, it's not what I want.
Post by Jason H
Q_PROPERTY (qreal scale READ scale WRITE setScale NOTIFY scaleChanged)
// What I end up writing
Post by Jason H
Q_PROPERTY (qreal scale MEMBER _scale NOTIFY) // What I want to write
qreal scale() { return _scale; }
void setScale(qreal scale) { if (scale != scale) { _scale = scale; emit
scaleChanged(scale); } }
Post by Jason H
void scaleChanged(qreal scale);
Where T=type, N=name M=member
T N() { return M; }
void setN(T N) { if (M != N) { M = N; emit NChanged(N); } }
void NChanged(T N);
class X {
...
INCLUDE_AUTOMOC_DECLARATIONS
};
Where
#include "filename_X_automoc.h"
Where MOC has written the declarations. Similarly, there can be one for
implementations as well.
Post by Jason H
Q_PROPERTY (qreal scale NOTIFY)
T _N;
T N() { return _N; }
void setN(T N) { if (_N != N) { M = N; emit NChanged(N); } }
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).
Post by Jason H
Is there any way to get closer to my ideal?
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
Jason H
2018-12-06 17:10:51 UTC
Permalink
_______________________________________________
Interest mailing list
***@lists.qt-project.org
https://lists.qt-project.org/listinfo/interest
Jason H
2018-12-06 17:15:17 UTC
Permalink
How, where? I flipped through the menus, and I didn't see anything that looked relevant.

When creating a class that includes Q_OBJECT, I am not prompted for property.
When I context menu a class, I don't get an "Add Properties..." like in Eclipse.

Thanks
Sent: Wednesday, December 05, 2018 at 12:14 PM
Subject: Re: [Interest] Better Q_PROPERTY() ?
use QtCreator, so you can autogenerate most of the code there
Post by Jason H
I've been doing a lot of Q_PROPERTY stuff again, and I waste too much time writing boiler plate code. Last time, I was reminded of the MEMBER modifier, which is what I thought I wanted. But after having worked with it some more, it's not what I want.
Q_PROPERTY (qreal scale READ scale WRITE setScale NOTIFY scaleChanged) // What I end up writing
Q_PROPERTY (qreal scale MEMBER _scale NOTIFY) // What I want to write
qreal scale() { return _scale; }
void setScale(qreal scale) { if (scale != scale) { _scale = scale; emit scaleChanged(scale); } }
void scaleChanged(qreal scale);
Where T=type, N=name M=member
T N() { return M; }
void setN(T N) { if (M != N) { M = N; emit NChanged(N); } }
void NChanged(T N);
class X {
...
INCLUDE_AUTOMOC_DECLARATIONS
};
Where
#include "filename_X_automoc.h"
Where MOC has written the declarations. Similarly, there can be one for implementations as well.
Q_PROPERTY (qreal scale NOTIFY)
T _N;
T N() { return _N; }
void setN(T N) { if (_N != N) { M = N; emit NChanged(N); } }
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?
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
Konstantin Shegunov
2018-12-06 18:15:30 UTC
Permalink
Post by Jason H
How, where? I flipped through the menus, and I didn't see anything that looked relevant.
When creating a class that includes Q_OBJECT, I am not prompted for property.
When I context menu a class, I don't get an "Add Properties..." like in Eclipse.
Thanks
Over the Q_PROPERTY, the context menu (i.e. right click): Refactor >
Generate missing Q_PROPERTY members.
Jason H
2018-12-06 17:20:38 UTC
Permalink
Ah, found it, I have to Refactor from Context menu on a Q_PROPERTY. (Thanks Sérgio!)
Sent: Wednesday, December 05, 2018 at 12:14 PM
Subject: Re: [Interest] Better Q_PROPERTY() ?
use QtCreator, so you can autogenerate most of the code there
Post by Jason H
I've been doing a lot of Q_PROPERTY stuff again, and I waste too much time writing boiler plate code. Last time, I was reminded of the MEMBER modifier, which is what I thought I wanted. But after having worked with it some more, it's not what I want.
Q_PROPERTY (qreal scale READ scale WRITE setScale NOTIFY scaleChanged) // What I end up writing
Q_PROPERTY (qreal scale MEMBER _scale NOTIFY) // What I want to write
qreal scale() { return _scale; }
void setScale(qreal scale) { if (scale != scale) { _scale = scale; emit scaleChanged(scale); } }
void scaleChanged(qreal scale);
Where T=type, N=name M=member
T N() { return M; }
void setN(T N) { if (M != N) { M = N; emit NChanged(N); } }
void NChanged(T N);
class X {
...
INCLUDE_AUTOMOC_DECLARATIONS
};
Where
#include "filename_X_automoc.h"
Where MOC has written the declarations. Similarly, there can be one for implementations as well.
Q_PROPERTY (qreal scale NOTIFY)
T _N;
T N() { return _N; }
void setN(T N) { if (_N != N) { M = N; emit NChanged(N); } }
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?
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
Tomasz Siekierda
2018-12-05 20:18:57 UTC
Permalink
On Wed, 5 Dec 2018 at 18:23, Sérgio Martins via Interest
Post by Jason H
T _N;
T N() { return _N; }
void setN(T N) { if (_N != N) { M = N; emit NChanged(N); } }
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.
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,
--
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
https://lists.qt-project.org/listinfo/interest
Konstantin Tokarev
2018-12-06 16:03:07 UTC
Permalink
Post by Tomasz Siekierda
On Wed, 5 Dec 2018 at 18:23, Sérgio Martins via Interest
 > T _N;
 > T N() { return _N; }
 > void setN(T N) { if (_N != N) { M = N; emit NChanged(N); } }
 > 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)
Post by Tomasz Siekierda
 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,
 --
 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
 https://lists.qt-project.org/listinfo/interest
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
--
Regards,
Konstantin
Jérôme Godbout
2018-12-06 17:49:37 UTC
Permalink
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-***@lists.qt-project.org> On Behalf Of Konstantin Tokarev
Sent: December 6, 2018 11:03 AM
To: Tomasz Siekierda <***@gmail.com>; ***@kdab.com
Cc: ***@qt-project.org
Subject: Re: [Interest] Better Q_PROPERTY() ?
Post by Tomasz Siekierda
On Wed, 5 Dec 2018 at 18:23, Sérgio Martins via Interest
 > T _N;
 > T N() { return _N; }
 > void setN(T N) { if (_N != N) { M = N; emit NChanged(N); } }
 > 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)
Post by Tomasz Siekierda
 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,
 --
 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
 https://lists.qt-project.org/listinfo/interest
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
--
Regards,
Konstantin

_______________________________________________
Interest mailing list
***@lists.qt-project.org
https://lists.qt-project.org/listinfo/interest
Fabrice Mousset | GEOCEPT GmbH
2018-12-07 07:03:20 UTC
Permalink
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.


I use this tools in my Qt/QML application, and it saves me so much time!

Regards

Fabrice
-----Ursprüngliche Nachricht-----
Godbout
Gesendet: Donnerstag, 6. Dezember 2018 18:50
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-----
Sent: December 6, 2018 11:03 AM
Subject: Re: [Interest] Better Q_PROPERTY() ?
Post by Tomasz Siekierda
On Wed, 5 Dec 2018 at 18:23, Sérgio Martins via Interest
 > T _N;
 > T N() { return _N; }
 > void setN(T N) { if (_N != N) { M = N; emit NChanged(N); } }
 > 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)
Post by Tomasz Siekierda
 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,
 --
 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
 https://lists.qt-project.org/listinfo/interest
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
--
Regards,
Konstantin
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
Pierre-Yves Siret
2018-12-07 12:00:37 UTC
Permalink
Post by Fabrice Mousset | GEOCEPT GmbH
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.
http://youtu.be/96XAaH97XYo
I use this tools in my Qt/QML application, and it saves me so much time!
Regards
Fabrice
I've used those and personnal macros before but I've since stopped from
doing it.

At first it's useful but then you need for example a property that's
computed from another one, or some special case properties.
Should I create a specific macro for this case used once or twice in the
project, or should I use a normal Q_PROPERTY and have a weird mix of non-Qt
macros and Q_PROPERTY, making your code less readable?
Sometimes l also want to set a breakpoint in a getter or setter, macros
don't help for that.
Post by Fabrice Mousset | GEOCEPT GmbH
Q_PROPERTY_RWN(proptype, arg) --> Q_PROPERTY(proptype arg READ arg
WRITE setArg NOTIFY argChanged)
Qt Creator makes it easy to write Q_PROPERTY with its snippets.
You can type Q_PROPERTY <ctrl-space> type <tab> name <return> and it will
generate Q_PROPERTY(type name READ name WRITE setName NOTIFY nameChanged)
You can add your own custom snippets if you want constant or non writable
properties.

The only gripe I have with Qt Creator regarding properties is its
Q_PROPERTY refactoring.
* It adds setters as slots (
https://bugreports.qt.io/browse/QTCREATORBUG-15779 )
* Non scalar types like QString are passed as value to the property setter
( whereas if you create a QString member variable and you do Refactor /
Create Setter Member Function, the QString is passed as a const ref)
* Notify signals have parameters

That means that when I refactor a Q_PROPERTY to add missing members, I have
to do a second manual pass where I :
1 - Remove the signal parameter in the signal declaration and remove it in
the setter definition
2 - Move the setter from the public slots to under the getter
3 - Refactor move their definition to the .cpp
4 - Remove the useless added new lines.

Regards,
Pierre-Yves
Jason H
2018-12-07 16:21:29 UTC
Permalink
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
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.
http://youtu.be/96XAaH97XYo
I use this tools in my Qt/QML application, and it saves me so much time!
Regards
Fabrice
-----Ursprüngliche Nachricht-----
Godbout
Gesendet: Donnerstag, 6. Dezember 2018 18:50
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-----
Sent: December 6, 2018 11:03 AM
Subject: Re: [Interest] Better Q_PROPERTY() ?
Post by Tomasz Siekierda
On Wed, 5 Dec 2018 at 18:23, Sérgio Martins via Interest
 > T _N;
 > T N() { return _N; }
 > void setN(T N) { if (_N != N) { M = N; emit NChanged(N); } }
 > 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)
Post by Tomasz Siekierda
 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,
 --
 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
 https://lists.qt-project.org/listinfo/interest
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
--
Regards,
Konstantin
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
Konstantin Tokarev
2018-12-07 16:24:37 UTC
Permalink
Post by Jason H
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
Post by Jason H
 Sent: Friday, December 07, 2018 at 8:03 AM
 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.
http://youtu.be/96XAaH97XYo
 I use this tools in my Qt/QML application, and it saves me so much time!
 Regards
 Fabrice
 > -----Ursprüngliche Nachricht-----
 > Godbout
 > Gesendet: Donnerstag, 6. Dezember 2018 18:50
 > 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-----
 > Tokarev
 > Sent: December 6, 2018 11:03 AM
 > Subject: Re: [Interest] Better Q_PROPERTY() ?
 >
 >
 >
 > > On Wed, 5 Dec 2018 at 18:23, Sérgio Martins via Interest
 > >>  > T _N;
 > >>  > T N() { return _N; }
 > >>  > void setN(T N) { if (_N != N) { M = N; emit NChanged(N); } }
 > >>  > 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,
 > >>  --
 > >>  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
 > >>  https://lists.qt-project.org/listinfo/interest
 > >
 > > _______________________________________________
 > > Interest mailing list
 > > https://lists.qt-project.org/listinfo/interest
 >
 > --
 > Regards,
 > Konstantin
 >
 > _______________________________________________
 > Interest mailing list
 > https://lists.qt-project.org/listinfo/interest
 > _______________________________________________
 > Interest mailing list
 > https://lists.qt-project.org/listinfo/interest
 _______________________________________________
 Interest mailing list
 https://lists.qt-project.org/listinfo/interest
--
Regards,
Konstantin
Continue reading on narkive:
Loading...