How to instantiate a QObject type in rust and own that type? Or how to build a QList of that type within rust.

[ChrisCochrun]

Let's say that I have a type that I implement QListElement for and then need to generate an arbritrary number of them to be contained in a vec or QList within another type. I know from #1008 that I can use make_unique() on the bridge to get a UniquePtr. But what I haven't found is to take that type and put it into a QList and only after building the list of types send them back to QML.

Do I store that as a vec of type T, if so how do we translate UniquePtr to T? Or is it necessary to implement QListElement for UniquePtr? I have the required info to make the item in rust and so would rather to keep that backend code in rust rather than needing to round trip back to QML.

I've also just toyed with storing a plain rust type and using QMap_QString_QVariant and transforming that to and from the rust type as well. Just prefer stronger types in as many places as I can get to ensure that things are doing what they should.

[ahayzen-kdab]

Hey, I think maybe an example of what is being attempted might help for this question :-)

Generally yes if you want to add a type T to QList you need to implement QListElement for the T.

However storing a UnqiuePtr in a list might be curious if that list is copied anywhere, maybe a SharedPtr would work better, but depends exactly what you are doing there.

What I would say is that if you want to use the Rust types as much as possible then yes using a Vec<T> on the Rust side in the private state is probably best. Then only when you are exposing things to Qt convert / copy / construct them to a type that Qt understands.

So eg you could have your Vec in Rust be the source of truth with correct typing and borrowing rules then you in a property getter/invokable convert that to a QList or as you say a QVariantMap or something that Qt understands. This leads to Rust managing the "backend" code and Qt just observing it as a "view". Then maybe you need extra methods to manipulate the content that might need other Qt friendly types or enums as parameters that are then converted into whatever T understands. Effectively i'm saying you might have an abstraction layer in your QObject, so T <-> Glue to Qt friendly types in your QObject Rust definition <-> Qt UI.

But it depends exactly what you are trying to achieve here so maybe a minimal example of the problem could help with some suggestions. As you might also be trying to be declarative on the QML side which can lead to fun.

[ahayzen-kdab]

Ah I also just noticed you mentioned the T itself might be a QObject*. So for QObjects Qt generally handles them as raw pointers with a parent set and then you store them as a QPointer locally.

Now that we have got casting working in the latest CXX-Qt code it would likely be worth us adding eg QList<QObject*> as an existing binding. Whether we could also get QPointer going and store that we would have to see.

But from a Qt point of view a lot of the time you just set the parent in the constructor and the object is destroyed when it's parent is destroyed or when it is explicitly destroyed (with eg deleteLater()).

I think we should have a think generally around this area now that we have casting working though and if there is anything else that can be done to help the developer, cc @LeonMatthesKDAB