Draft: Add support for attributes to #[qproperty]

[CarlSchwan]

Make it possible to define if only a getter should be generated or only a setter and/or define special getter and setter.

Syntax is as follow

struct MyObject {
    #[qproperty]
    prop1: f32, // generate default getter and setter

    #[qproperty(get)]
    prop2: f32, // generate default getter only

    #[qproperty(set)]
    prop3: f32, // generate default setter only

    #[qproperty(get = Self::prop4_fn)]
    prop4: f32, // use prop4_fn as getter
}

WIP since the custom getter part doesn't work yet

[ahayzen-kdab]

Also note the clippy warnings :-)

[LeonMatthesKDAB]

@CarlSchwan good to see this change progressing nicely :+1:

Quick chime-in on the #[qproperty(get=Self::x)] API. I've just noticed that the Self:: part might be redundant, or even misleading in the worst-case, so it would be simpler to just leave it out in favor of #[qproperty(get=x)].

The Self:: within the struct MyObject technically refers to MyObject, not qobject::MyObject, but the getter x must be implemented on qobject::MyObject, so Self:: doesn't really refer to the right struct, technically. Furthermore, a getter (or setter for that matter) must always be implemented on the qobject:: of the given struct, so there's no real point of listing the Self::, it's just boilerplate I think and parsing would be simplified by removing it.

Or is there any way one could specify a getter/setter that is not on the qobject::MyObject? :thinking:

[CarlSchwan]

@CarlSchwan good to see this change progressing nicely +1

Quick chime-in on the #[qproperty(get=Self::x)] API. I've just noticed that the Self:: part might be redundant, or even misleading in the worst-case, so it would be simpler to just leave it out in favor of #[qproperty(get=x)].

The Self:: within the struct MyObject technically refers to MyObject, not qobject::MyObject, but the getter x must be implemented on qobject::MyObject, so Self:: doesn't really refer to the right struct, technically. Furthermore, a getter (or setter for that matter) must always be implemented on the qobject:: of the given struct, so there's no real point of listing the Self::, it's just boilerplate I think and parsing would be simplified by removing it.

Or is there any way one could specify a getter/setter that is not on the qobject::MyObject? thinking

I don't think there is a way to specify a getter/setter that is not on the qobject::MyObject and I don't think this would make sense. Regarding the syntax, I often prefer to make stuff more explicit and adding Self:: make it explicit and I originally tried to have the custom getter/settter in the MyObject instead of the qobject::MyObject but I didn't manage to do it. Syntax wise my objective is to have something as convenient as gtk-rs https://gtk-rs.org/gtk-rs-core/stable/latest/docs/glib/derive.Properties.html which are quite nice.

But there are still quite some work needed to get there.

[LeonMatthesKDAB]

I don't think there is a way to specify a getter/setter that is not on the qobject::MyObject and I don't think this would make sense. Regarding the syntax, I often prefer to make stuff more explicit and adding Self:: make it explicit and I originally tried to have the custom getter/settter in the MyObject instead of the qobject::MyObject but I didn't manage to do it. Syntax wise my objective is to have something as convenient as gtk-rs https://gtk-rs.org/gtk-rs-core/stable/latest/docs/glib/derive.Properties.html which are quite nice.

But there are still quite some work needed to get there.

IMHO, we should still just leave out the Self:: part then, it's more "explicit", but also points you to the wrong object!

GTK-rs also seems to just use the function name.

[LeonMatthesKDAB]

Superseded by #994