Q_PROPERTY Creator integration and possible accessor naming convention standardization?

[utcenter]

Two quick ideas to make working with properties faster, easier and more consistent:

First - integrate Q_PROPERTY support in Creator to automatically generate header declarations and cpp definitions for the property accessors. Pretty straightforward, saves some typing and helps avoid potential typos.

Second - standardize a naming convention for Q_PROPERTY accessor methods. Saves some more typing and enforces a fixed naming convention so you never really have to ever check how is a particular accessor named. Naturally, this means the actual accessors, singals and data types can and should be automatically generated.

So instead of:
@Q_PROPERTY(int number READ number WRITE setNumber RESET resetNumber NOTIFY numberChanged)@

you simply:
@Q_PROPERTY(int number READ WRITE RESET NOTIFY)@

The convention - rather simple and intuitive - so enforcing it should rise no problems and will ensure consistency and faster workflow

bq. the READ method shall always be (property) name
the WRITE method shall always be setName (camel case)
the RESET method shall always be resetName
the NOTIFY method shall always be nameChanged
the property member shall always be m_name

Stuff like property revisioning, scriptable and so on should still be specified, since those appear to be rarely used and mostly relying on property defaults.

The two suggestions combined together should make for a considerable improvement when working with properties, which are pretty much mandatory for extending both C++ and QtQuick APIs in Qt.

Also, if backward compatibility is an issue, the Q_PROPERTY macro should remain the same and a new macro should be introduced to handle the automatic name generation.

[kitizz]

I very much agree =D
I found this page when doing a quick search to see if anyone else had had the same annoyances/ideas as me. This is pretty much spot on.

How would you feel about collaborating on making something like this happen?

One of us takes a task each =)

[utcenter]

Well, there are basically two routes for this happening:

1 - create a feature request, get enough people to vote for it, and hope it will eventually find its way into Qt

2 - implement the future ourselves, offer it up for including in the framework, and hope it will eventually find its way into Qt

I myself am not a particularly seasoned developer, naturally I can generate the required code, but when it comes to extending Creator - I am pretty much in the dark. I guess it would be fairly easy to make it as a plugin, it will not need to pass through the slower process of approving it as core functionality.

[utcenter]

Aaaaand... done:

!http://i48.tinypic.com/35c2xqs.png(Qt property generator)!

Resulting code:

@ // Auto generated property frameSize : QSize
// comment goes here
Q_PROPERTY(QSize frameSize READ frameSize WRITE setFrameSize RESET resetFrameSize NOTIFY frameSizeChanged REVISION 2 DESIGNABLE false SCRIPTABLE false STORED false USER true CONSTANT FINAL)
private: QSize m_frameSize;

Q_SLOT inline QSize frameSize() {
    return m_frameSize;
}
Q_SLOT inline MyClass &setFrameSize(const QSize &v) {
    m_frameSize = v;
    return *this;
}
Q_SLOT inline void resetFrameSize() {
    // TODO reset
}
Q_SIGNAL void frameSizeChanged(QSize);@

Now if someone is willing to put it into a Creator plugin. Alternatively, it can be used stand alone...

[kitizz]

Yup, I was pushing for number two =)

We should kick up an issue in any case, I'll scratch one up shortly and post the link here. I've had some experience with Qt source development, I helped out a little with QML as an intern back when Nokia still owned Qt.

I envision a "smart" plugin that keeps track of the function declarations and implementations in both the .h and .cpp files of a class. Something that would enable the property to be renamed easily.

Someone might argue that this is what QML is for. But as you pointed out, sometimes you just need to write it in C++.

I'm going to begin looking into Creator plugin development tonight, get a feel for it.

[kitizz]

Wait, nevermind, found this fellow:
https://bugreports.qt-project.org/browse/QTCREATORBUG-1532

[utcenter]

That is almost 3 years old and still not solved :)

[andre]

Did you know that if you just type
@
Q_PROPERTY (int test READ test WRITE setTest NOTIFY testChanged)
@
and then press ALT-Enter on that in Creator, you already get the option to auto-generate the getter, the setter and have the notify properly connected?

[kitizz]

gasp That's almost perfect =D
Thank you Andre!

Though I think I might see if it can be extended so that it places the implementation in the .cpp

[utcenter]

[quote author="Andre" date="1360671493"]Did you know that [/quote]

Obviously not :)

[andre]

[quote author="utcenter" date="1360671251"]That is almost 3 years old and still not solved :)[/quote]

I'd say it is is solved actually. Just not marked as such... I added a comment on that to the report.

[andre]

[quote author="utcenter" date="1360671815"][quote author="Andre" date="1360671493"]Did you know that [/quote]

Obviously not :)

[/quote]

Note that your generator does quite a bit more than the simple implementation in QtCreator, but it is not as nicely integrated of course. I do think that extending the implementation in QtCreator probably makes more sense than continue building your own. I'd like to see the one in creator get the feature to generate the code in the .cpp file instead, and you might be missing your chaining feature. Also, of course, the actual Q_PROPERTY declaration is not generated for you. It might be nice to find a good spot for that as well. Perhaps under a right-click or an ALT-Enter on the Q_OBJECT macro would be a nice place to add a Create New Q_PROPERTY command, that would show a little dialog with the different options...

[kitizz]

Good thoughts, I like it =)
I might put it on my Rainy Days list.

[utcenter]

Actually, I am considering creating a node based visual tool for programming that generates C++ source. Not just stubs but to replace typing altogether, with the exception of identifiers and stuff like that. Including visual class hierarchy editors, custom components that are like boilerplate snippets with UI and so on.

I did some testing, it actually takes less space and memory than text source editors. Plus it is impossible to make typos, and developing should be somewhat faster and less constrained by the actual language syntax. My initial plan was to do something very basic as an educational tool, but it is possible to implement the entire C++ standard. Plus there are some cool possibilities, like pinning "probe" values to parameters and test-running functions without compiling, much like a debugger, but on the actual program nodes.

When that's done, I guess Qt support can be hacked in fairly easy by people who are familiar with the Qt internals.

[tobias.hunger]

Andre: https://codereview.qt-project.org/#change,47638 adds a snippet for Q_PROPERTY to 2.7. Not perfect (the setter name is wrong...), but better than nothing (and something that could be done in a minute;-).

[andre]

@Tobias: how would this work in practice? I am not familiar with the snippets stuff... Would this ask for the $name, and then generate the rest, or does the name come from somewhere else? Anyway, thanks for the quick action!

[tobias.hunger]

Andre: Just type Q_PROP and trigger code completion. You can then select the Q_PROPERTY snippet and it will enter it as shown in Tools>Options>Text Editor>Snippets>C++. Using tab you can switch between the different variables and fill them in.

Note that Q_PROPERTY is considered an illegal trigger in anything but the 2.7 branch, so in 2.6.2 you will need to select a different trigger text (e.g. PROPERTY).