Open LeonMatthesKDAB opened 1 year ago
From #584, for auto generated getter/setter should of properties should they always be pub methods ? Then if the developer wants something different they can use the custom getter/setter?
I think this makes sense but just wanted to check if we need any more changes in the API, but seems likely not.
Original comments
what do we do about the visibility of the getter/setter/notify when they are auto generated?
At the moment we always generate them as pub, maybe this is fine ?
Maybe if you want the getter/setter/notify to be pub(crate) or not pub you should use a custom getter/setter/notify ?
As in Qt/C++ if you have a Q_PROPERTY even if the methods aren't public you can always ( ? ) use the QMetaProperty / meta object system to read / write the properties ? So they are always "public" ?
As #[qproperty(T, NAME)] is supposed to be a shorthand for #[qproperty(T, NAME, read = Self::my_getter, write = Self::my_setter)], to me it seems that the shorthand could just always generate as pub visibility then custom stuff can do anything else.
Otherwise we'd need the API to be #[qproperty(pub, T, NAME)] or #[qproperty(pub T, NAME)] #[qproperty(T, pub NAME)] or something thinking
Does #[qinvokable(cxx_override)]
become
#[qvinokable]
#[cxx_override]
As we need to be able to support making an override on just a C++ method and not a qinvokable as well ? eg #298
Does
#[qinvokable(cxx_override)]
become#[qvinokable] #[cxx_override]
As we need to be able to support making an override on just a C++ method and not a qinvokable as well ? eg #298
I think that makes sense, yes.
Is the following code legacy/deprecated? Should I use extern "RustQt"
like in the examples folder?
Edit: Is the book up to date?
Edit2: How do I include cxx-qt-gen headers in a CMake project directly in C++, not QML?
#[cxx_qt::qobject]
pub struct FooBar {
#[qproperty]
number: i32,
#[qproperty]
string: QString,
}
// ...
impl qobject::FooBar {
#[qinvokable]
pub fn increment_number(self: Pin<&mut Self>) {
let previous = *self.as_ref().number();
self.set_number(previous + 1);
}
#[qinvokable]
pub fn say_hi(&self, string: &QString, number: i32) {
println!("Hi from Rust! String is '{string}' and number is {number}");
}
}
Hi @axelkar ,
happy to hear you're interested in CXX-Qt. Yes, the code you're showing is unfortunately going to be deprecated with the next release (we're aiming to release in the next few weeks). For most of our public documentation (e.g. the book and docs.rs) it always shows the currently stable version. The book is therefore only up-to-date to the current release, not the current development version. We will of course update the book with the next release as well. If you want to preview the new book, take a look at PR #687 .
The core concepts of CXX-Qt are not going to change. However the API will be different and a lot closer to CXX.
Porting to 0.6 should be a relatively straight-forward, if a bit boring task.
If you're feeling adventurous, feel free to depend directly on CXX-Qt main
to try out the new API.
Most existing 0.5 features are working there with the new API already, though some details can change without notice on master, as CXX-Qt is not stable yet.
In our opinion, the new API is ever so slightly more verbose, but it should make the aim of CXX-Qt much clearer. The goal is to provide a bridge similar to CXX that just declares, but doesn't define the concepts that should be available on both sides of the bridge. CXX-Qt just adds qobject, qenum, qsignals, qinvokables and other Qt concepts to this bridge. This should make it easy to learn CXX-Qt for existing CXX, as well as Qt developers, as the API is very similar to existing CXX, as well as to a normal QObject declaration in C++. That's why we think that's the API we can stabilize on.
We're always looking for feedback, so please feel free to leave any thoughts, concerns and suggestions under this issue :blush:
Regarding your second question:
Take a look at the CMakeLists.txt in the qml_minimal example.
CXX-Qt's output directory is controlled using the CXXQT_EXPORT_DIR
environment variable.
Inside that each crate gets its own directory.
Inside each crates directory, you'll find header files in these subdirectories:
So to include the header file for the qobject generated by rust/src/cxxqt_object.rs
inside qml_minimal you'd need to write:
#include <cxx-qt-gen/qobject.cxxqt.h>
As the ${CXXQT_EXPORT_DIR}/${CRATE}
is added to the include path.
We need to figure out a plan for QFlags maybe something with https://crates.io/crates/bitflags and https://crates.io/crates/flagset etc
After discussions following #531, we believe we've found an improved API that we want to target for Cxx-Qt 1.0.
Anyone using Cxx-Qt, feel free to leave feedback on this issue.
Solved API problems
527 -
extern "Qt"
block &extern "RustQt"
block531 - you explicitly define the QObject type now!
529 - Documentation should now show up correctly
294 - Multiple bridges should no longer collide, as we no longer require the qobject:: prefix
404 - Results can now be represented the same way as in CXX
42 - Clearly define the available Q_PROPERTY attributes
Drawbacks
1.0 API Overview
The point of this API is to be even closer to CXX than before, by only putting declarations within the bridge itself. We've found this preferable for
#[inherit]
, as well as for#[qsignal]
for a while now, but haven't found a good API for QProperty. We believe by simply using a#[qproperty()]
attribute this can be solved nicely!