Since signal are not sync all the time but can be async, the argument need to be copiable to allow this. So you need to be able to copy the arguments on the signals. Therefore the QObject is not copiable, they cannot be passed as arguments directly, you need a pointer. The ownership and lifetime of that object is up to you, but you need it to live until all handler have finish processing the signal (this can be longer then the signal emit for queued connection).
If you can easily copy the structure you probably can serialize/deserialize it or put it into a QVariant, QVariantList or QVariantMap. That would be copiable. From: Sylvain Pointeau <sylvain.point...@gmail.com> Sent: March 1, 2019 11:15 AM To: Jérôme Godbout <godbo...@amotus.ca> Cc: Qt Project <interest@qt-project.org> Subject: Re: [Interest] using a custom class as parameter of signal/slot, used in QML Hello Jerome, On Fri, Mar 1, 2019 at 3:34 PM Jérôme Godbout <godbo...@amotus.ca<mailto:godbo...@amotus.ca>> wrote: The fact that the QObject is non copiable, is one of the reason it need a pointer (which can be copied). As for the ownership, you can check with the qqmlengine: https://doc.qt.io/qt-5/qqmlengine.html#objectOwnership I have understood it yes You can change the ownership too with setOwnership(). I for one exposed the methods to Qml so each side can check/set the qobject ownership based on the needs. This is very helpful to debug. You can use QPointer to have a pointer that will return to null if the qobject get deleted. OK but I thought a signal should be quite generic, and not necessarily consumed by QML. but maybe we should design special signals for QML, is this what you suggest? I would find more convenient to be able to send a structure by copy, so consumed as it is by QML (wrapped in QML and ownership set to QML) Best regards, Sylvain
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
