fix: fix signal connection between GUI and guiclass instance #693
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #690
This PR implements
TwoWaySetAttr
class for synchronization between widget and guiclass to safely handle the following problem.The tricky part was that how many times signals will be emitted depends on the implementation of how values are set to the magicgui widget and to the backend widget.
Because Qt spin box widget does not emit Qt signal when the same value was set, the signal chain is like this:
obj.gui.x.value
changedobj.x
obj.events.x
obj.gui.x.value
However, because the signal emissions of ListEdit is handled on the magicgui side, the signal chain becomes like this:
obj.gui.x.value
changed ← first timeobj.x
obj.events.x
obj.gui.x.value
obj.gui.x.value
changed ← second timeobj.x
obj.events.x
because same value was set, thanks to the implementation ofpsygnal.evented
(We can consider 6. as a bug of
ListEdit
: it emits signal when the same value was set. In my opinion, this implementation should be left as is because checking values such aslist[np.ndarray]
is time consuming ... but let's leave this in other issues if we need more discussion)Even if we carefully implement all the
set_value
methods, we may still have problems if a set-value method of some GUI library emits signal regardless of whether the old and new values are the same. The safest solution I think is to connect callbacks that can stop recursive two-way emission by itself.