4 ms·
Your notquick [0], "a nice workflow for emails that works for me", is similar to a topic I've thought about a lot and which was one of the reasons to start RQBG
by oever 8y ago
Your notquick [0], "a nice workflow for emails that works for me", is similar to a topic I've thought about a lot and which was one of the reasons to start RQBG. (I'd like to tie my mail more to my projects and tasks via content addressable storage and RDF). Coding in Rust is fantastic, but the GUI options are not there yet. Hence RQBG which is meant to stay small (<3k lines atm).
Your project uses it in the right way: just commit the generated files. It's a drag and error-prone to write so much binding code by hand.
> some additional work where properties can be writeable references to Rust objects
You can nest objects. The demo code does this. Here's an example where both Parent and Child are a QObject:
"objects": {
"Child": {
"type": "Object",
"properties": [
"name": {
"type": "QString"
}
]
},
"Parent": {
"type": "Object",
"properties": [
"child": {
"type": "Child"
}
]
}
}
> some additional work [...] where I hope to make QML objects (list items) possible to create from Rust
You'd like to use object types as itemProperties as well? That's not possible at the moment, but a logical extension.
Experimenting in your own branch is a good way to start. Wishes and designs for them can be discussed in the issue tracker: https://bugs.kde.org/describecomponents.cgi?product=rust-qt-binding-generator https://bugs.kde.org/describecomponents.cgi?product=rust-qt-...
Currently, generated model code derives from QObject (Object) or QAbstractItemModel (List and Tree). Deriving from QWidget or QQuickItem would make it possible to write GUI components in Rust as well. Those classes are large though and I've not yet had the urge/need to try that.
- rhn_mk1 8y agoBy writeable references, I meant replacing one QML reference by another: RustFoo {id: "foo"} RustBar { foo_field: foo } This is possible with my branch. Your above example needs to be amended the following way: "child": { "type": "Child", + "write": "true" } The API changes quite a bit unfortunately, and is no longer so nice to use. Unfortunately, my ideas to use (read-only) objects in itemProperties all end up complicating the API even worse, with abundant Box<>es and wrappers over wrappers. I can't find an elegant way to work around the mismatch between some Rust and C++ concepts (mostly lifetimes), but I expect to come up with something worth discussing within a couple of weeks.
- oever 8y ago> The API changes quite a bit unfortunately, and is no longer so nice to use. The object property could be changed to use QSharedPointer<X> when it is writable instead of a raw pointer (const X*). The setter could be done completely in C++ initially, since the main use case, as you show, is to assign that value in QML or Qt code. > objects in itemProperties [..] I expect to come up with something worth discussing within a couple of weeks Looking forward to it! For any Qt, QML or Rust experts reading this: I'd love your keen eyes on the generated code from Rust Qt Binding Generator.