-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move QObject type & property into extern "RustQt"
#559
Comments
Note that once there is a The ForeignItemFn in extern "RustQt" can be just passed through in the generator rust phase to the inner extern "Rust" block, as the self type is then correct. We don't need to store the self type and rebuild the function. |
Although note we still have the wrapper fun coming from C++ -> Rust, so maybe this can't be removed for invokables. For inherit and signals going the other way though this should be possible. |
First step is to move the Then once that is done, we can move the struct outside the bridge and type alias with the qproperty attribute inside. |
As we move qproperty to an attribute we need to disable generating helpers for fields as we won't be able to find them when the struct is outside the bridge. There are three options going forwards - let the developer create their own getters/setters (this commit) - add a #[field(T, NAME)] as an attribute to the qobject later - remove the (un)safe for qproperty with notify so that rust_mut is safe Related to KDAB#559
This is a stepping stone to moving qproperty to be defined on the type in the extern "RustQt" block. Related to KDAB#559
We might be able to turn the parser phase here into something more like a continuous ParseStream, but would be a larger refactor. |
As we move qproperty to an attribute we need to disable generating helpers for fields as we won't be able to find them when the struct is outside the bridge. There are three options going forwards - let the developer create their own getters/setters (this commit) - add a #[field(T, NAME)] as an attribute to the qobject later - remove the (un)safe for qproperty with notify so that rust_mut is safe Related to KDAB#559
As we move qproperty to an attribute we need to disable generating helpers for fields as we won't be able to find them when the struct is outside the bridge. There are three options going forwards - let the developer create their own getters/setters (this commit) - add a #[field(T, NAME)] as an attribute to the qobject later - remove the (un)safe for qproperty with notify so that rust_mut is safe Related to KDAB#559
This is a stepping stone to moving qproperty to be defined on the type in the extern "RustQt" block. Related to KDAB#559
As we move qproperty to an attribute we need to disable generating helpers for fields as we won't be able to find them when the struct is outside the bridge. There are three options going forwards - let the developer create their own getters/setters (this commit) - add a #[field(T, NAME)] as an attribute to the qobject later - remove the (un)safe for qproperty with notify so that rust_mut is safe Related to KDAB#559
This is a stepping stone to moving qproperty to be defined on the type in the extern "RustQt" block. Related to KDAB#559
As rust_mut is now safe. Related to KDAB#559
This is a stepping stone to moving qproperty to be defined on the type in the extern "RustQt" block. Related to KDAB#559
As we move qproperty to an attribute we need to disable generating helpers for fields as we won't be able to find them when the struct is outside the bridge. There are three options going forwards - let the developer create their own getters/setters (this commit) - add a #[field(T, NAME)] as an attribute to the qobject later - remove the (un)safe for qproperty with notify so that rust_mut is safe Related to #559
This is a stepping stone to moving qproperty to be defined on the type in the extern "RustQt" block. Related to #559
Although not sure it's worth the gain as we still need to generate the other methods from the same info. Related to KDAB#559
This is done now. |
As discussed in #555
extern "RustQt"
block.The text was updated successfully, but these errors were encountered: