feat: add request_values convenience, shows modal dialog to request values

[tlambert03]

adds magicgui.widgets.show_values_dialog which lets you show a modal dialog to retrieve a set of values from the user

In [1]: from magicgui.widgets import request_values

In [2]: request_values(param_a=int, param_b=str, title='asdfsd')
Out[2]: {'param_a': 0, 'param_b': ''}

other examples:

    >>> from magicgui.widgets import request_values

    >>> request_values(age=int, name=str, title="Hi! Who are you?")

    >>> request_values(
    ...     age=dict(value=40),
    ...     name=dict(annotation=str, label="Enter your name:"),
    ...     title="Hi! Who are you?"
    ... )

    >>> request_values(
    ...     values={'age': int, 'name': str},
    ...     title="Hi! Who are you?"
    ... )

[codecov]

Codecov Report

Merging #416 (8f5443a) into main (1ac1d58) will decrease coverage by 0.05%.
The diff coverage is 85.71%.

@@            Coverage Diff             @@
##             main     #416      +/-   ##
==========================================
- Coverage   88.87%   88.81%   -0.06%     
==========================================
  Files          30       30              
  Lines        3865     3917      +52     
==========================================
+ Hits         3435     3479      +44     
- Misses        430      438       +8     

Impacted Files	Coverage Δ
magicgui/backends/_qtpy/__init__.py	100.00% <ø> (ø)
magicgui/widgets/_function_gui.py	94.01% <ø> (-0.06%)	⬇️
magicgui/backends/_qtpy/widgets.py	86.26% <74.07%> (-0.41%)	⬇️
magicgui/widgets/_dialogs.py	77.27% <93.75%> (+34.41%)	⬆️
magicgui/widgets/__init__.py	100.00% <100.00%> (ø)
magicgui/widgets/_bases/container_widget.py	93.08% <100.00%> (+0.22%)	⬆️
magicgui/widgets/_concrete.py	86.73% <100.00%> (+0.07%)	⬆️
magicgui/widgets/_protocols.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1ac1d58...8f5443a. Read the comment docs.

[tlambert03]

@ctrueden and @gselzer, this is partially in response to some recent discussions. Lemme know what you think of the API

[gselzer]

@tlambert03 this is cool, and the API is pretty succinct! The documentation for the widget type is nice, too.

Do you have some use cases in mind?

[tlambert03]

Do you have some use cases in mind?

yes, i got thinking about this from the New Image discussion. For example, if you needed to collect some input (size, content, dtype, etc) to create a new image.

In general, this could be used by napari anytime a command requires parameters

[gselzer]

Gotcha, thanks.

I think I'm just having a bit of trouble thinking through when to use request_values over a plain call to magicgui. I think this request_values thing is pretty lightweight in that it can't do anything with the values, right?

Since the major benefit of this functionality is convenience, I keep wondering if it would be useful to allow a postprocessing routine in the signature.

For example, if you picked up the size, content, dtype, etc. for the new image command, you could pass a function to request_values that, after value selection, turned all of those values into an image, and that's the only output you get from the request_values call. Or in the case of napari-imagej you could have a postprocessing function that turns all of the python values into their java equivalents.

But that seems to close to what magicgui is supposed to do? Maybe we need a section on when to use this vs. magicgui.

[tlambert03]

I think I'm just having a bit of trouble thinking through when to use request_values over a plain call to magicgui. I think this request_values thing is pretty lightweight in that it can't do anything with the values, right?

yep, much more lightweight. makes no assumptions about what someone is doing with the values downstream. In general actually, I kinda think @magicgui itself is being abused/overused a bit, as the "only" way to retrieve values from a user. So I'd like to gradually build some lower level stuff that gets used more often.

I keep wondering if it would be useful to allow a postprocessing routine in the signature.

I can see the potential usefulness there. maybe for a follow up PR though. Currently, since request_values blocks, you would just achieve it as follows:

if values := request_values(...):
    do_something_with_values(**values)

[gselzer]

In general actually, I kinda think @magicgui itself is being abused/overused a bit, as the "only" way to retrieve values from a user.

I definitely agree, and may be guilty of this in napari-imagej 😅

I can see the potential usefulness there. maybe for a follow up PR though. Currently, since request_values blocks, you would just achieve it as follows:

do_something_with_values(**request_values(...))

Yup, definitely should not go in this PR, especially as I cannot imagine how I'd want the API for that to look. Do you need to specify the output types of the Callable in the signature somehow? I'd think you should, especially if the Callable alters the number of inputs you are returning, but how would that look best?

Maybe we could add a modal option for magicgui...