GUI mechanism for editing widget parameters

[alisterburt]

I saw in the meeting yesterday that you're working around the idea of using Annotated to provide extra information needed for widget generation, which is perfect for programmatic use but does require that a user knows what's being generated requires this extra info and how to supply it.

def gaussian(
    image : Image,
    sigma : Annotated[float, FloatRange(1, 100)],
) -> Image:

With provide_functions from napari/napari#2080 there was some discussion about requiring this annotation system being an extra burden on users. I think users on the napari side are less likely to know about the specific requirements of magicgui for annotating this extra info.

Maybe this burden could be alleviated a bit by providing a GUI mechanism for editing widget parameters from the generated GUI. In terms of UI, I'm imagining a small arrow like the one on the right here, for a menu. From the menu you could open a floating window with little boxes for each of the editable parameters.

The presence of this little arrow would default to off and probably only show up in cases like when magicgui is being used inside another system like napari. Another possible benefit of this system is the ability to optimise things like slider ranges 'on-the-fly'. Rather than going through the generate magicgui -> play with slider -> update function annotation loop as many times as is needed, someone developing an application could just modify on the fly and update the annotation once.

Would love to hear your thoughts, totally possible that what I'm proposing isn't really useful. If you think this is useful I'd love to develop it myself but may need some guidance!

[tlambert03]

I think users on the napari side are less likely to know about the specific requirements of magicgui for annotating this extra info.

that's a very good point. I do think we'll need to make it clearer that we're using the same API as magicgui when providing those widget parameters.

Maybe this burden could be alleviated a bit by providing a GUI mechanism for editing widget parameters from the generated GUI... Rather than going through the generate magicgui -> play with slider -> update function annotation loop as many times as is needed, someone developing an application could just modify on the fly and update the annotation once.

oh yeah, that would be awesome. (kinda like what we did with the contrast-limits slider in napari... which probably nobody still knows about because it's hard to find! 😆 )

This sounds like a feasible (though kinda big?) undertaking in something like Qt ... but I'm not sure how doable it would be in other backends (like #87)? I think it could also be challenging to strike the right balance between minimal ui and flexibility... maybe just a single faint "gear" icon in the corner of the container gui, that, when clicked, pops up it's own "meta gui" with the parameters for each of the widgets in the container?

anyway, I'm definitely intrigued by the idea!

[alisterburt]

I had no idea the contrast limits slider limits could be adjusted!! So useful

Glad to hear the idea isn't totally off base - and 'meta gui' is a great name for it. Your UI idea is great too! You're right that ipywidgets doesn't have any obvious way to make this feasible.

If I start working on the backend side of it, mapping widget types to sets of configurable parameters I guess we can move forward from there?

[tlambert03]

Sure! That’s actually a much needed specification anyway. You’ll notice in the types.py file, I have a WidgetOptions typed dict. That concept needs to be expanded, but should really be tied somehow to the signatures of the various widget subclasses in _bases.py

Feel free to take a crack at it, we can iterate on it together

On Jan 8, 2021, at 4:35 AM, alisterburt [email protected] wrote:

 I had no idea the contrast limits slider limits could be adjusted!! So useful

Glad to hear the idea isn't totally off base - and 'meta gui' is a great name for it. Your UI idea is great too! You're right that ipywidgets doesn't have any obvious way to make this feasible.

If I start working on the backend side of it, mapping widget types to sets of configurable parameters I guess we can move forward from there?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[alisterburt]

Cool I'll start from there and try to come up with a nice way of doing it all dynamically