Riateche
commented
8 years ago Parsing signals and slots
Before generating code, we need to know which signals and slots do exist in each class. Clang already provides information about all methods, including their types and visibility, and we just need to figure out which of them are signals and slots. I think it's better to do it by searching for Q_SIGNALS, Q_SLOTS and other visibility tokens in the header and determining which methods are declared within signals and slots sections. IIRC, moc does it this way (I'll take a look at its source).
Some versions of QObject::connect require text representation of the method. In C++, it's usually used with a macro, like SIGNAL(bytesWritten(qint64)), but it's pretty much equivalent to "2bytesWritten(qint64)" ("1" means slot and "2" means signal). It turns out Qt is smart enough to recognize the method as "bytesWritten(long long)" (while qint64 is a define for "long long"), so there should be no significant problems in constructing text representation.
An alternative way is to use QMetaObject to request information about signals and slots at runtime, during an additional step of parsing. It would be harder to make a mistake there, but it significantly complicates the process.
Types of connect()
There are 3 general types of QObject::connect:
- using text representation of sender and receiver;
- using pointers to member functions of sender and receiver;
- using pointer to member function of sender and functor as receiver.
There is no way to expose pointers to member functions through FFI because it involves C++ template magic and compile-time checks. The only way would be to generate connect statements for each available pairs of sender and receiver, and it's just not reasonable.
Connecting to a functor could probably be useful, but it would still require generation of the connect statement for each available sender. I would rather not do it if I don't have to. I think creating slots on Rust side will be as easy as connecting to functors in C++, so there is no point in implementing it.
So, we only need to support connect via text representation:
QMetaObject::Connection connect(const QObject* sender, const char* signal, const QObject* receiver, const char* method, Qt::ConnectionType type = Qt::AutoConnection)Creating signals and slots in Rust
Rust users will want to interact with Qt via signals and slots, but they will not need to use them for communication within their Rust applications. So, there is no need to declare custom types in Qt metatype system. There is no point in creating signals and slots with arguments that doesn't correspond to those encountered in Qt, because there wouldn't anything they could be connected to. Each Qt library has limited set of arguments, and we can generate specialized code to make signals and slots with these arguments available.
The easiest way I can see is to generate a QObject subclass containing a signal or a slot for each list of arguments:
class QSignalWrapperQInt64 : public QObject {
Q_OBJECT
signals:
void method(qint64);
};
class QSlotWrapperQInt64 : public QObject {
Q_OBJECT
public:
QSlotWrapperQInt64(void (*func)(void*, qint64), void* data);
public slots:
void method(qint64);
private:
void (*m_func)(void*, qint64);
void* m_data;
};
QSlotWrapperQInt64::QSlotWrapperQInt64(void (*func)(void *, qint64), void *data) {
m_func = func;
m_data = data;
}
void QSlotWrapperQInt64::method(qint64 arg1) {
m_func(m_data, arg1);
}The slot wrapper provides a callback parameter, and I believe it makes passing Rust closures as callbacks a lot easier. The Rust API will expose constructors of these classes and the method to send the signal (if it's a signal). The Rust struct will contain a CppBox with a QObject pointer. C++ object will be deleted when the struct goes out of scope, ensuring automatic disconnect. Creating an object with signals and slots in Rust would be looking like this:
impl MyStruct {
pub fn new() -> MyStruct {
MyStruct {
my_data: 42,
my_signal1: qt_core::custom_signal::SignalI64::new(),
my_slot1: qt_core::custom_slot::SlotI64::new(|x| {
println!("received number: {}", x);
})
}
}
fn emit_example(&self) {
self.my_signal1.emit(42);
}
}I suspect Rust will not be happy if you try to borrow something inside the closure. But it will be right. Using RefCell to make it happy is an acceptable solution in this case.
At first, I thought we can put all signals and slots into one class. But what if someone wants to use two different signals of the same type? They would still need to create multiple objects. Creating a QObject for each signal or slot provides more flexible situation. And the Rust struct keeps ownership of the objects, so it can delete them all at once without any complications.
Slot wrappers should probably expose QObject::sender() protected method. It's the only way to figure out where the signal came from in case of multiple connections. It can be done by creating another constructor that accepts closure with an additional argument. That argument will have the value of sender():
qt_core::custom_slot::SlotI64::new_with_sender(|sender, x| {
println!("received number: {} from {:?}", x, sender);
})Slot wrappers should have invoke(...) method to call the slot directly.
Rust connect API
Like in PyQt, I would like to have signal and slot objects instead of raw QObject::connect interface. Each object can provide QObject* pointer to the object and const char* representation of the method. Each signal or slot also should have a type parameter indicating argument types or the method, and Rust API will enforce that the types are compatible. A signal object will have a connect() function that receives another signal or slot object and optionally a connection mode.
Rust's custom signal and slot wrapper structs will implement signal and slot interface, obviously. Qt's own QObjects will have methods returning signal and slot objects, but those objects will not own the QObject and will not attempt to delete it. Some examples:
// connect native signal to native slot
widget.signals().destroyed().connect(app.slots().quit());
// connect native signal to custom signal
let my_signal1 = qt_core::custom_signal::SignalI64::new();
file.signals().bytes_written().connect(&my_signal1);Rust disconnect API
The signal's connect() function will return Result<meta_object::Connection>, and the connection object will have disconnect() method that is forwarded to this C++ method:
bool QObject::disconnect(const QMetaObject::Connection & connection)Signal objects will also have disconnect() method that receives the same data as connect() and allows to disconnect signals without having a connection object.
Qt also has wildcard disconnect options that can be exposed. QObject wrappers will have disconnect_all() and disconnect_one() methods to disconnect all receivers or one receiver (all signals and slots), and a signal object will have disconnect_all() method to disconnect everything from this signal.
This is a work in progress. I will be happy to discuss the details and hear any suggestions.
emoon
I wonder if you have thought about how this would work? I was pointed to this on the users forum
https://github.com/White-Oak/qml-rust/blob/master/examples/qobjects.rs#L16
https://github.com/White-Oak/qml-rust/blob/master/src/macros.rs#L90
It seems fairly complex but I'm not sure how QObject works in details. Regardless slots & signals are a pretty big part of working with Qt so I wonder if you have any ideas of how this could be implemented?