Nested QObjects and MyObjectQt API

[LeonMatthesKDAB]

With our move to a more direct integration with CXX and our new API changes, we have to think about how to represent Nested QObjects in future and how they should be defined in CXX-Qt.

What works and what doesn't

We should do the least amount of work to make nested objects work, such that the integration with existing CXX features is as clear and flexible as possible.

Things that already work out-of-the-box:

• Have another MyObjectB in MyObjectA by value, but that will not be a QObject!
• Use UniquePtr to refer to another Opaque C++ type that is owned
• Use Pin<&mut MyQObject> in invokable arguments to refer to another QObject temporarily.
• Using Raw pointers - Not really desireable, but is basically the only thing we can do if we want a QObject that can be set by QML.

Which means we mostly have means to refer to ownership (UniquePtr, vs. Pin<&mut>) within a cxx-qt defined QObject.
Related: dtolnay/cxx#1091 - which will make using UniquePtr from within a MyObject a bit easier.

What we have to figure out:

• How to refer to the QObject<MyObjectB> in another CXX-Qt, and also non-CXX-Qt Module.
• When and how to do appropriate conversions between T* <-> UniquePtr <-> Pin<&mut T> , etc.
• Stretch goal: Set up Connections between different QObjects on the Rust side?

Referring to a foreign QObject

This issue has two targets:

1. If we're within a CXX module, we need to declare the C++ opaque type as coming from another module.
2. We might want to hand around these QObjects in normal Rust code, so we need to support that as well.

QObject<MyObjectB>

I think being able to refer to another QObject like that would be ideal.

However, this has a few problems. We need to be able to declare the QObject as an opaque C++ type in CXX.
But CXX won't allow something like this, without modification:

#[cxx_qt::bridge]
mod ffi {
extern "C++" {
    // This is not a valid foreign type definition for CXX.
    // We could automatically convert this, but we were hoping not to have to do any conversion in `extern "C++"` blocks.
    type AnotherObj = cxx_qt::QObject<crate::my_other_mod::MyObject>
}
}

Also, it's not entirely clear how refererring to a QObject in any free piece of Rust, code would work.

QObject!(MyObjectB)

The QObject<MyObjectB> syntax could be replaced by a QObject! macro that adds the Qt appendix to the named type.
This would require a nightly experimental feature: https://doc.rust-lang.org/std/macro.concat_idents.html

This might work with cxx, depending on which macro is executed first. eg.:

#[cxx_qt::bridge]
mod ffi {
extern "C++" {
    type AnotherObj = cxx_qt::QObject!(crate::my_other_mod::MyObject)
}
}

There are a few problems with this though, for example, something like:

let my_obj = QObject!(MyObject)::new();

does not work, it must be this instead:

let my_obj = <QObject!(MyObject)>::new();

Which isn't terrible, but also not ideal.

Associated types

If we think about it the real problem we have is that we have a second type that is hidden, which is our QObject.
So a possibly good way to communicate this is through an associated type.
Unfortunately, associated types are only available on traits. But we could create a QObject trait like this:

pub trait QObject {
    type QObject;
}

impl QObject for MyObject {
    type QObject = ffi::MyObjectQt;
}

Then in another module, one could refer to this type quite easily:

#[cxx_qt::bridge]
mod ffi {
extern "C++" {
    type AnotherObj = <crate::my_other_mod::MyObject as QObject>::QObject
}
}

The unfortunate part here really is that you always need the as syntax for disambiguation.
See: rust-lang/rust#38078
However, once you define the type AnotherObject = ... you will then be able to use AnotherObj to refer to this type for the rest of the cxx bridge.

The more annoying part would be changing the impl cxx_qt::QObject<>
As it would make sense to use the same syntax there:
However, this is actually not valid in normal Rust, so we would have to rewrite it, like we do already anyways.

impl <MyObject as QObject>::QObject {
   #[qinvokable] 
    pub fn ....
}

Using MyObjectQt directly

We can just drop the pretense and use MyObjectQt directly. This is rather an exercise in teaching than anything else, as its not at all obvious where this type is coming from.

Possible solution:
Let you define the name of your MyObjectQt struct directly, for example by making it a required argument: cxx_qt::QObject(MyObjectQt).
We might even want to drop the C++ naming conversion, and use MyObjectQt as the C++ name of the struct directly, as you're now able to define both names.
Even though that makes naming ab it annoying, as you always have one struct named suboptimally.

[LeonMatthesKDAB]

Why not swap the default?

Instead of trying to teach people that we auto-generate a new MyObjectQt type, why not instead generate a MyObjectRust type, and simply make MyObject the QObject type.

We can then still use associated types to give you access to the MyObjectRust type in a sane way.
Mostly we expect users to use MyObjectQt anyway, so using the Rust type is an advanced feature, so there a bit of annoying syntax isn't as much of a problem.

So example of associated types:

pub trait CxxQtObject {
    type Rust; // or maybe Inner?
}

impl CxxQtObject for MyObject {
    type Rust = MyObjectRust;
}

Then you could use the inner type as:

<MyObject as CxxQtObject>::Rust

[LeonMatthesKDAB]

Problem that has been noticed by @ahayzen-kdab :
We still need access to the MyObject::Rust, because we expect this to impl Default.

So it's rather strange to expect developers to know they have to write:
impl Default for <MyObject as CxxQtObject>::Rust
Especially as they have just declared the struct MyObject a few lines above...

[LeonMatthesKDAB]

See: #237 (comment)

[ahayzen-kdab]

Swap the names around

• MyObject becomes MyObjectRust
• MyObjectQt becomes MyObject
• impl block is then normal
• nested types can just use MyObject as normal.

[ahayzen-kdab]

Swapping the types creates a really nice API, however it has the fun of

• we need to rename any trait impls, eg impl Default for MyObject -> MyObjectRust (easy to do)
• what if the developer wants to impl something on the C++ object?

/// Needs to rename to MyObjectRust
#[cxx_qt::qobject]
struct MyObject { ... }

/// Invokables go on Rust and CXX, non invokables go on just CXX
impl MyObject {
  #[qinvokable] 
  fn invokable() { ... }

  fn cpp_context() { ... }
}

/// Needs to rename MyObject -> MyObjectRust
impl Default for MyObject { ... }

/// is this for the C++ context or the Rust context ?
impl Thing for MyObject { ... }

/// Currently with the above we default for impl blocks going on CXX and impl traits going on the Rust context
/// What if we had an attribute to pick ?
#[cxx_qt::context(CXX)]
impl Thing for MyObject { ... }

#[cxx_qt::context(Rust)]
impl MyObject { ... }

[LeonMatthesKDAB]

Suggestion: Using Modules

Idea: Make a MyObject Module, that contains a QObject type.
That would allow for a syntax of MyObject::QObject to refer to the QObject version of the struct.

Problems:

We can't have a module that contains a struct named MyObject, as well as a module named MyObject:
e.g., this doesn't compile:

pub struct MyStruct {
    pub x: i32,
}
mod MyStruct {
    pub struct QObject {
        pub y: i32,
    }
}

Solution 1

Alternatively, we could have a MyStruct module, with a Rust and a QObject struct in it.
Even though that's also syntactically somewhat strange.

#[cxx_qt::qobject]
struct MyStruct {
    #[qproperty]
    pub x: i32
}
// replaced by cxx-qt with:
mod MyStruct {
    pub struct Rust {
        pub x: i32,
    }
    type QObject = MyStructQt
}

Solution 2

Maybe we could create a QObject module instead:

#[cxx_qt::qobject]
struct MyStruct {
    #[qproperty]
    x: i32,
}
// generated by cxx-qt
#[allow(non_snake_case)]
mod QObject {
    type MyStruct = MyStructQt
}

This would allow you to refer to:

1. MyStruct as the Rust struct
2. QObject::MyStruct as the QObject 🥳
   This should work without issue from other CXX modules as well.

[ahayzen-kdab]

Solution 2 seems pretty natural and covers all the cases, even nested objects looks sane.