-
-
Notifications
You must be signed in to change notification settings - Fork 410
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add example linking the cameras of two viewers #6881
base: main
Are you sure you want to change the base?
Conversation
This simulates multi-view multicanvas. Based on: https://forum.image.sc/t/zooming-in-on-the-same-region-on-two-different-layers/95659/5
This pull request has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/zooming-in-on-the-same-region-on-two-different-layers/95659/8 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lovely 🥰
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #6881 +/- ##
==========================================
- Coverage 92.45% 92.43% -0.02%
==========================================
Files 617 617
Lines 55156 55156
==========================================
- Hits 50993 50986 -7
- Misses 4163 4170 +7 ☔ View full report in Codecov by Sentry. |
viewer0.camera.events.zoom.connect( | ||
lambda ev: set_zoom(viewer1.camera, ev.value) | ||
) | ||
viewer1.camera.events.zoom.connect( | ||
lambda ev: set_zoom(viewer0.camera, ev.value) | ||
) | ||
viewer0.camera.events.center.connect( | ||
lambda ev: set_center(viewer1.camera, ev.value) | ||
) | ||
viewer1.camera.events.center.connect( | ||
lambda ev: set_center(viewer0.camera, ev.value) | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should not use lambdas in examples in signal connection. It is a bad pattern when someone tries to do this in plugin code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain in more detail @Czaki? Why is it a bad pattern?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Would a tz.curried function be better?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because lambdas keep hard references to objects from their namespaces, that leads to leaking objects and preventing gc from deleting obsolete objects. And when we referring Qt objects, it may refer to objects that were deleted by qt and leads to segfaults.
Of course, it is not this case, but someone may inspire by example and cause problems.
I suggest use event.source
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we put that info as a comment or in the header of the example? "If you want to do this in a plugin be aware x y z"
I like how straightforward this is. Not intimidating and easy to understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I presume not every object should be a partial — in the discussion in pyapp-kit/app-model#183, you talk about "simple" and "complex" objects but I don't know what this distinction means... Is "simple" just a built-in type?
By simple, I mean object, which leaking is not a problem. So number, text, aray of texts, simple mapping dictionary, list of ints, pydantic model ith simple fields are simple. But Layer, Viewer, non small numpy array, some evented object, list of layers, dict with mapping from name to viewer etc, means complex in this case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By simple, I mean object, which leaking is not a problem.
That still isn't clear to me. And I think it's a critical question because, for example, if I make a partial with a reference to particular number and I connect it, I want to keep that reference so the parameter, which is needed at call time, is not gc'd. Can one write a function is_simple_object
that determines this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that you should update this example to use this utility main/napari%2Futils%2Fevents%2Fevent_utils.py#L63
Not until that's cleaned up 😂 (better name + better docs). I will try to do some of that in this PR.
But it's a useful model, thanks for pointing me to it. Getting some ideas... I think it should be possible to make our own partial that does a similar kind of wrapping/unwrapping? 🤔
From https://docs.python.org/3/library/weakref.html#weakref.ref:
class weakref.ref(object[, callback])
[...] If callback is provided and not None, and the returned weakref object is still alive, the callback will be called when the object is about to be finalized; the weak reference object will be passed as the only parameter to the callback; the referent will no longer be available.
That's interesting. Can we make self-disconnecting connections using weakrefs? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make self-disconnecting connections using weakrefs? 🤔
(I see that this is what the utility does. But it does this on callback time, rather than when the object is destroyed using the weakref callback, and I'm also wondering whether we can do this with connect
directly, rather than with a utility. Or maybe with a decorator?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's interesting. Can we make self-disconnecting connections using weakrefs? 🤔
we have tried in the past, and we ended with segfaults.. (Qt related..). Whis is why there are lines:
if (ob := ref()) is None:
emitter.disconnect(_cb)
return
in the code.
Can one write a function
is_simple_object
that determines this?
Such a function will need to go through the whole dependency graph, and this could be really time-consuming. And still may be a problem with edge cases.
But we could do simpler thing that search in depth 3 or 5 only and validate if some well known problematic class is present (layer, viewer, np.ndarray of size above 1000 etc).
This simulates multi-view multicanvas.
Based on: https://forum.image.sc/t/zooming-in-on-the-same-region-on-two-different-layers/95659/5