Draft: Add support for attributes to #[qproperty] #451

CarlSchwan · 2023-02-20T21:20:31Z

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

crates/cxx-qt-gen/src/generator/rust/property/mod.rs

ahayzen-kdab · 2023-02-21T10:06:34Z

crates/cxx-qt-gen/src/generator/rust/qobject.rs

@@ -33,6 +33,7 @@ impl GeneratedRustQObjectBlocks {
    }
 }

+#[derive(Debug)]


any reasoning for these extra derive Debug's ? They could be done in a separate commit if they are useful ...

Mostly for debugging, I'll remove then

CarlSchwan · 2023-02-20T21:31:51Z

crates/cxx-qt-gen/src/generator/cpp/property/mod.rs

+        let default_setter = match property.set {
+            Some(MaybeCustomFn::Default) => true,
+            _ => false,
+        };


Suggested change

let default_setter = match property.set {

Some(MaybeCustomFn::Default) => true,

_ => false,

};

CarlSchwan · 2023-02-21T10:09:26Z

crates/cxx-qt-gen/src/generator/rust/qobject.rs

@@ -33,6 +33,7 @@ impl GeneratedRustQObjectBlocks {
    }
 }

+#[derive(Debug)]


Mostly for debugging, I'll remove then

ahayzen-kdab · 2023-02-21T10:49:55Z

Also note the clippy warnings :-)

ahayzen-kdab · 2023-02-21T10:55:25Z

crates/cxx-qt-gen/src/generator/cpp/property/meta.rs

@@ -4,15 +4,30 @@
 // SPDX-License-Identifier: MIT OR Apache-2.0


don't forget to add an entry to the CHANGELOG.md :-)

And update anything in the book and we'll have to find somewhere in the properties example of qml_features to use it

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 ```rust 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 Signed-off-by: Carl Schwan <[email protected]>

CarlSchwan · 2023-04-27T14:59:03Z

crates/cxx-qt-build/src/lib.rs

@@ -407,7 +407,7 @@ impl CxxQtBuilder {
        // Use a separate cc::Build for the little amount of code that needs to be linked with +whole-archive
        // to avoid bloating the binary.
        let mut cc_builder_whole_archive = cc::Build::new();
-        cc_builder_whole_archive.link_lib_modifier("+whole-archive");
+        //cc_builder_whole_archive.link_lib_modifier("+whole-archive");


Suggested change

//cc_builder_whole_archive.link_lib_modifier("+whole-archive");

remove before merging

LeonMatthesKDAB · 2023-04-28T08:08:15Z

@CarlSchwan good to see this change progressing nicely 👍

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? 🤔

CarlSchwan · 2023-05-02T09:35:09Z

@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 · 2023-05-02T11:56:42Z

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 · 2024-07-22T14:38:03Z

Superseded by #994

CarlSchwan marked this pull request as draft February 20, 2023 21:20

ahayzen-kdab mentioned this pull request Feb 21, 2023

Consider which attributes should be on a Q_PROPERTY #42

Closed

ahayzen-kdab reviewed Feb 21, 2023

View reviewed changes

crates/cxx-qt-gen/src/generator/rust/property/mod.rs Show resolved Hide resolved

ahayzen-kdab reviewed Feb 21, 2023

View reviewed changes

CarlSchwan commented Feb 21, 2023

View reviewed changes

ahayzen-kdab reviewed Feb 21, 2023

View reviewed changes

Carl Schwan added 2 commits April 27, 2023 15:21

Make custom getter work

3928c86

CarlSchwan force-pushed the work/carl/custom-getter branch from a6171e2 to 3928c86 Compare April 27, 2023 14:58

CarlSchwan commented Apr 27, 2023

View reviewed changes

ahayzen-kdab mentioned this pull request Jun 7, 2023

C++ property types for setter/getter #297

Closed

LeonMatthesKDAB closed this Jul 22, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Draft: Add support for attributes to #[qproperty] #451

Draft: Add support for attributes to #[qproperty] #451

CarlSchwan commented Feb 20, 2023

ahayzen-kdab Feb 21, 2023

CarlSchwan Feb 21, 2023

CarlSchwan Feb 20, 2023

CarlSchwan Feb 21, 2023

ahayzen-kdab commented Feb 21, 2023

ahayzen-kdab Feb 21, 2023

CarlSchwan Apr 27, 2023

LeonMatthesKDAB commented Apr 28, 2023

CarlSchwan commented May 2, 2023

LeonMatthesKDAB commented May 2, 2023

LeonMatthesKDAB commented Jul 22, 2024

		@@ -4,15 +4,30 @@
		// SPDX-License-Identifier: MIT OR Apache-2.0

Draft: Add support for attributes to #[qproperty] #451

Draft: Add support for attributes to #[qproperty] #451

Conversation

CarlSchwan commented Feb 20, 2023

ahayzen-kdab Feb 21, 2023

Choose a reason for hiding this comment

CarlSchwan Feb 21, 2023

Choose a reason for hiding this comment

CarlSchwan Feb 20, 2023

Choose a reason for hiding this comment

CarlSchwan Feb 21, 2023

Choose a reason for hiding this comment

ahayzen-kdab commented Feb 21, 2023

ahayzen-kdab Feb 21, 2023

Choose a reason for hiding this comment

CarlSchwan Apr 27, 2023

Choose a reason for hiding this comment

LeonMatthesKDAB commented Apr 28, 2023

CarlSchwan commented May 2, 2023

LeonMatthesKDAB commented May 2, 2023

LeonMatthesKDAB commented Jul 22, 2024