I had defined a slot on one object with the @QtCore.Slot(object) decorator, and a slot with QtCore.Signal(object) on another, connected these and wanted to emit the signal from another thread, so that a queued connection would be used. But the slot was still called from the other thread.
This is what I used for the connection:
source.signal.connect(dest.slot)
When I replaced this with
source.connect("signal(PythonQtSafeObjectPtr)", dest, "slot(PythonQtSafeObjectPtr)")
it worked as intended.
What hat happened? I had made the connect in the other thread. PythonQt didn't "realize" that this is a slot on a object, but only "saw" a Python callable and internally created a PythonQtSignalReceiver. Since it was created in the other thread, it lived in this thread, and no queued connection was used.
In the second version, the connect was done to the slot of the dest object, which lived in the main thread, which made Qt use a queued (asynchronous) connection.
I believe on a connect of the first kind PythonQt should first check if this is an existing slot of an object and use that for the connection instead of creating a PythonQtSignalReceiver for the callable, because this is a reasonable expectation of the user. The same logic should apply for connections from signals to signals.
Note: Since this might change the behavior of existing connections, this should at least be a minor version update.
I had defined a slot on one object with the @QtCore.Slot(object) decorator, and a slot with QtCore.Signal(object) on another, connected these and wanted to emit the signal from another thread, so that a queued connection would be used. But the slot was still called from the other thread.
This is what I used for the connection:
source.signal.connect(dest.slot)When I replaced this with
source.connect("signal(PythonQtSafeObjectPtr)", dest, "slot(PythonQtSafeObjectPtr)")it worked as intended.
What hat happened? I had made the connect in the other thread. PythonQt didn't "realize" that this is a slot on a object, but only "saw" a Python callable and internally created a PythonQtSignalReceiver. Since it was created in the other thread, it lived in this thread, and no queued connection was used.
In the second version, the connect was done to the slot of the dest object, which lived in the main thread, which made Qt use a queued (asynchronous) connection.
I believe on a connect of the first kind PythonQt should first check if this is an existing slot of an object and use that for the connection instead of creating a PythonQtSignalReceiver for the callable, because this is a reasonable expectation of the user. The same logic should apply for connections from signals to signals.
Note: Since this might change the behavior of existing connections, this should at least be a minor version update.