Display selected custom view parameters as widgets

[jlstevens]

This issue summarizes some discussion I've had with @philippjfr and @jbednar about how best to generate widgets for custom view parameters. Here are the three options we talked about:

1. Use param precedence according to the usual panel semantics when converting parameters to widgets.
2. Declaring constant=True for the parameters that shouldn't be shown as widgets.
3. Explicitly list which parameters should become widgets (by name) in the yaml declaration.

Personally, I like option 3 the most as it is the most explicit and lets you easily set the widget order in the yaml. Then I like option 1 as it is consistent with how panel displays widgets for parameters and I like option 3 the least.

[jbednar]

I vote for all 3. People should be able to declare parameters as constant, and if they do, then why show them? Supporting 2 just seems like correct behavior. Same for 1 -- the mechanism is already there, and respecting it seems fully appropriate. 3 is an option that is probably useful and convenient, so it doesn't have to be supported but does seem like a good idea.

If all 3 are supported, the question becomes which mechanism we promote and explain as the appropriate or typical way. I'll leave that call to Philipp; it's really about storytelling and narrative and pitching, so it's best to have one voice for that (Philipp).

[jlstevens]

I agree that constant parameters probably don't need widgets. I suppose I would encourage people to use option 3 but if no explicit list is given, the fallback should be option 2 (with option 1 applying as well).

[philippjfr]

Honestly I think popping up a bunch of parameters (or rather widgets) by default is surprising and I'm not sure you can always decide ahead of time which parameters it makes sense to expose so I'm leaning towards 3. as the main mechanism here. But if that is the main mechanism I'm having a hard time seeing what supporting options 1. and 2. would add here or how that would even work.

[jlstevens]

I see you settled on an explicit controls attribute in the PR above which is my preferred option (though can the yaml expand the controls beyond the list declared on the class?). At any rate, it sounds like this issue can be closed now.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.