You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Connection to a user-defined slot just uses the callable #363
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.
This has mostly been fixed with the fix for issue #362. Not in the way that the signal is connected to the defined slot, but the signal is connected to an internal receiver object that should always live in the same thread as the intended receiver object, so the behavior in regard to the connection type should be the same. The differences that arise from not actually using the defined slot but a receiver proxy should rarely matter in practice.
Since I don't expect to invest more work into this issue, I will close it for now.
Activity
Do a regular signal/slot connect if the argument is a slot object,
Do a regular signal/slot connect if the argument is a slot object,
Do a regular signal/slot connect if the argument is a slot object,
Create a separate receiver object for each signal/callable connect
Create a separate receiver object for each signal/callable connect
Create a separate receiver object for each signal/callable connect
usiems commentedon Sep 2, 2026
This has mostly been fixed with the fix for issue #362. Not in the way that the signal is connected to the defined slot, but the signal is connected to an internal receiver object that should always live in the same thread as the intended receiver object, so the behavior in regard to the connection type should be the same. The differences that arise from not actually using the defined slot but a receiver proxy should rarely matter in practice.
Since I don't expect to invest more work into this issue, I will close it for now.