Create a separate receiver object for each signal/callable connect - #365
Conversation
f78e9bf to
3390891
Compare
mrbean-bremen
left a comment
There was a problem hiding this comment.
Looks good as far as I can see (though I may miss some possible implications)
So connect(signal, f); connect(signal, f); disconnect(signal, f) now disconnects both, where previously it disconnected one. This actually matches Qt's native disconnect semantics (removes all matching connections), so it's arguably more correct — but it's a behavior change worth documenting in the PR description / changelog since the author already flagged thread-related behavior changes.
|
Thanks for the hint! I could change it back if you would feel better about it, otherwise I will just document the change.
I looked it up: The variant with the QObject* argument exists at least since Qt 5.6 (I would guess since Qt 5.0), and we don't support older Qt versions anymore since PythonQt 4. |
This way we can't run out of slot IDs. This fixes #362 This also enables us to associate the receiver with the instance object of the callable (if it is a method of a QObject-derived class) instead of the sender, so that it is associated with the correct thread, which is important for the AutoConnection used. In a way this also fixes the problem in #363 Note that this commit also changes the disconnect behavior slightly in that all connections to a callable are removed, while previously only a single connection was removed when there were multiple connections from the same signal to the same callable.
63601e6 to
d1f2df0
Compare
This way we can't run out of slot IDs.
This fixes #362
This also enables us to associate the receiver with the instance object of the callable (if it is a method of a QObject-derived class) instead of the sender, so that it is associated with the correct thread, which is important for the AutoConnection used.
In a way this also fixes the problem in #363, because now the receiver object should always live in the same thread as the self object of the callable. The connection to a callable doesn't use the actual slot defined by a slot decorator, but the effect should be largely the same.
Note that this might change the behavior of signal/callable connections when threads are used, so users need to test if their uses still work for them.