-
-
Notifications
You must be signed in to change notification settings - Fork 415
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 support for function widgets #1856
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1856 +/- ##
==========================================
+ Coverage 79.78% 79.82% +0.03%
==========================================
Files 387 388 +1
Lines 33215 33234 +19
==========================================
+ Hits 26501 26529 +28
+ Misses 6714 6705 -9
Continue to review full report at Codecov.
|
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.
this looks great to me @sofroniewn, exactly how I pictured it. I made a couple small implementation comments. but don't feel strongly on any of them
I've made a couple issues on the magic gui around being able to use strings for types, see napari/magicgui#46 and napari/magicgui#47.
totally agree. will do.
I'm also curious about the ramifications of the API changes in napari/magicgui#43,
The main change as it relates to this PR would be around the .Gui()
syntax (which was always a bit weird). Briefly, the new magicgui
decorator will return an instance of magicgui.FunctionGui
, which itself is a magicgui widget (rather than simply adding a function attribute Gui
that points to the widget). outside of napari, that object could be shown just with decorated_function.show()
(or decorated_function.show(run=True)
to spin up an event loop). To get at the actual QWidget
, you would now use .native
, much like how vispy does it. so, in this PR, you'd change it to
widget = magicgui(**magic)(function).native
but otherwise, it shouldn't change much here. To get a more complete idea about what is changing from the API perspective, have a look at how the "examples" are changing in https://github.com/napari/magicgui/pull/43/files
oh... also, after https://github.com/napari/magicgui/pull/43/
|
will each widget always have a |
not all widgets, but all
it depends on how the categorical widget was created. In this case though, a parameter annotated as a napari |
Do I then need to add a check to see if the function/ attribute exists or is it always safe to try and connect in the way I'm doing? |
ohhh, right! good point :) yeah, I think we'll need to check. but actually, this concept probably belongs in |
For now I'll check and then make an issue to follow-up |
until the magicgui API changes, all widgets will have a |
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 agree with almost everything @tlambert03 wrote. The broad strokes here though are super great, and I think @sofroniewn will know how to wrap this up, so I'm providing my approval pending the discussed changes.
Ok great sounds like we're pretty close. Out of curiosity @tlambert03 do you have guestimate on a timeline for how long it would take to finish https://github.com/napari/magicgui/pull/43? I just looked and we don't actually depend on magicgui yet - I need to add that to this PR - and if possible it might be nice to make our first dependency on a version after that PR has merged, but I don't think that's a requirement. |
the code is mostly done, (just need to add back labels). The main issues now are tests, and updated docs... and that's unfortunately why it's sat there for a while. but I can probably just live with imperfect test coverage for the first . probably a week or two of focused work? (question is when will the focused work come 😂) |
ok sounds good, we can play it by ear! |
Given https://github.com/napari/magicgui/pull/43 and how much that will change the API, I think we should probably hold off on this until 0.4.2, despite (or perhaps because of!) the massive community excitement about this. In short, I think many people would start using this immediately, and it would become a major backwards-compatibility headache. Let's take a couple of more weeks and get this right? (Or at least, a little more right. 😂) |
yeah, I think that's a good idea. While the decorator syntax itself won't change too dramatically, the fact that accessing the widget with edit: jeez, I'm realizing now that even the original post there is a bit out of date. so if you want to maximize your review efforts, maybe hold off on that too for a week or so |
Agreed |
ahh... this is because magicgui resolves the forward reference as needed, but doesn't actually replace the type annotation. It would be easy enough to fix on the magicgui side (see https://github.com/napari/magicgui/issues/65). Otherwise, we'd also need to resolve them in def get_layers(...):
if layer_type is None:
gui, layer_type = gui.native, gui.annotation
# resolve the ref
if isinstance(layer_type, ForwardRef):
from magicgui.type_map import _evaluate_forwardref
layer_type = _evaluate_forwardref(layer_type) |
I think it's probably for the best to do this on the magicgui side, I made a PR: https://github.com/napari/magicgui/pull/66 |
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.
This looks great @sofroniewn! The examples definitely make it look even easier now to get some gui goodness into napari. :)
I left some thoughts, but you can take them or leave them. Also, if you want, you can remove the comments from utils._magicgui.get_layers
if we're going to depend on magicgui>=0.2.0
also: if you want, I try to get napari/magicgui#63, napari/magicgui#64, and napari/magicgui#65 in and release 0.2.1 tomorrow and you can pin to that instead? |
Co-authored-by: Talley Lambert <talley.lambert@gmail.com>
Co-authored-by: Talley Lambert <talley.lambert@gmail.com>
I've moved the auto-connection to the If you want to make a commit to this PR that cleans up
Sounds good, no rush |
# Keep the dropdown menus in the widget in sync with the layer model | ||
# if widget has a `reset_choices`, which is true for all magicgui | ||
# widgets | ||
self.qt_viewer.viewer.layers.events.connect(widget.reset_choices) |
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'm forgetting at the moment... is layers.events
the same as "any event" or did we need to do layers.events.inserted
and layers.events.removed
?
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.
layers.events
will do all of them
Co-authored-by: Talley Lambert <talley.lambert@gmail.com>
ok, I just cleaned up I figured out what was going wrong in #2044 and submitted fix in #2046. |
I've approved all 3 PRs, they all look good to me. If you want to make a magicgui |
Ok this has been updated to now depend on the latest magicgui |
good idea. I made a slight update to explain that ForwardRefs are mostly necessary if you don't want to import napari. all looks good to me i think! 🎉 |
Ok, great, will merge now!! |
Description
Following on from #1816, particularly discussion here #1816 (comment) this PR adds the ability to provide functions that we turn into dock widgets using magic gui via an
viewer.window.add_magic_function(function, magic, dock)
API, wherefunction
is the function,magic
is a dict that gets passed to themagicgui
method anddock
is a dict that gets passed toadd_dock_widget
method.This PR adds two examples
magic_image_arthimetic
andmagic_parameter_sweep
based on respective examples of in the magicgui docs https://magicgui.readthedocs.io/en/latest/I've made a couple issues on the magic gui around being able to use strings for types, see https://github.com/napari/magicgui/issues/46 and https://github.com/napari/magicgui/issues/47. I'm also curious about the ramifications of the API changes in https://github.com/napari/magicgui/pull/43, but we don't necessarily need to wait to release this until that is merged, though it might be nice.
Once we have this merged it will be much easier to continue with #1816 (or supercede it) as now a plugin will just be able to provide a list of tuples of inputs to
add_magic_function
.I havn't added tests yet, but will do so. I think it would be nice to get some review and input on this first though - cc @tlambert03 @GenevieveBuckley @jni
Type of change