Add extern "Qt" - allow signals on existing Qt classes

[ahayzen-kdab]

In #485 we start adding support for (dis)connecting in Rust, this works for QObjects defined in Rust.

However a QObject could be defined outside of Rust and we might want to (dis)connect from it's signals.

A possible solution would be to explore having an extern "Qt" block again, and then changing signals away from an enum to methods.

unsafe extern "Qt" {
   #[qsignal]
    fn my_signal(self: &MyQObject, param: QString);
}

#[cxx_qt::qobject]
struct MyQObject;

unsafe extern "Qt" {
    type QButton;
    #[qsignal]
    fn my_signal(self: &QButton, param: QString);
}

This would keep the way of defining a signal consistent to Rust and C++ QObjects, which then means the generation is the same for generating on_SIGNAL.

For the emit side we would likely need to consider removing converters #289 or the Rust my_signal would be renamed in CXX to the emitMySignal that performs any conversion.

I also wonder would we then put the inherit macro in this block too ?

unsafe extern "Qt" {
   #[qsignal]
    fn my_signal(self: &MyQObject, param: QString);

    #[inherit]
    #[cxx_name = "hasChildren"]
    fn has_children_super(self: &MyQObject, parent: &QModelIndex) -> bool;
}

#[cxx_qt::qobject(base = "QAbstractItemModel")]
struct MyQObject;

Guess one of the questions with that would be, is it qobject::MyQObject or MyQObject for the type ?

cc @LeonMatthesKDAB

[LeonMatthesKDAB]

For both signals, and inherit, we'll want to use qobject::MyQObject, as that's what they'll end up on. 🤔

[ahayzen-kdab]

For both signals, and inherit, we'll want to use qobject::MyQObject, as that's what they'll end up on. thinking

My question would then be, what happens for foreign QObjects ? eg type QButton ? Is the type here always referring to the TQt variant as there isn't a Rust version ? So for these you would use just T where as Rust based ones would use qobject::T.

[ahayzen-kdab]

We should figure out the larger question around T vs TQt and whether we want an extern "Qt" block in #531 first.

[LeonMatthesKDAB]

For results, see #555.

TL;DR: We'll want to introduce an extern "Qt" block as proposed in this issue + a extern "RustQt" for Rust-defined QObjects.

[ahayzen-kdab]

This can be combined into #577

[ahayzen-kdab]

Close in favour of #577