Open YooSunYoung opened 1 month ago
I was thinking the "select parameters" section could just be one big multiple-select containing both parameters and intermediate parameters all together (all domain types in the workflow).
I don't see the reason for keeping the distinction between intermediary and non-intermediary parameters.
One problem with this solution is that it is totally non obvious to the user which parameters can be set. Parts of defining "THE" parameter of the workflow is to document which inputs are required or options. Saying "any of the intermediate results of the workflow is an optional input" does not serve this important purpose.
Is your concern is that the user wont know what parameters to select in the big multiple-select list of parameters? That will be done automatically for them unless they manually change the settings that were made when they selected what outputs to target.
Then I do not understand the suggestion. For example, above it says
Instead of setting switchable to all the parameters, we can treat all parameters switchable, and have a menu of parameter from the workflow, just like we select output.
Can you give an example of how this would work for, say, https://github.com/scipp/esssans/blob/1c407162a50f4e68b843899f55384f5c025e19e7/src/ess/sans/parameters.py#L99-L104?
It's really not different from how it works currently.
The only change is that we add a multiple-select that determines what parameters are displayed in the ParameterBox
widget (the parameter form).
Here's the UX I'm imagining:
If the user wants to set an intermediate value, they open the parameters-multiple select and selects that value, then they re-generate the parameter form.
Example - SANS direct beam
Ok, so we keep the Parameter.switchable
field 👍
Ok, so we keep the Parameter.switchable field 👍
I think @YooSunYoung point was that removing switchable widget would make it easier to style the parameter form.
I was refering to class Parameter
, not the widget itself. Are you suggesting that there should be a different mechanism outside Parameter
that defines which parameters of the workflow are switchable by default?
I was refering to class Parameter, not the widget itself. Are you suggesting that there should be a different mechanism outside Parameter that defines which parameters of the workflow are switchable by default?
No I don't have an opinion on that
For clarity here are a couple of screenshots illustrating the idea:
Ignoring the collapsed "Manually select parameters" accordion makes the interface the same as what we have today. If you open the "Manually select parameters" menu you can select intermediate values to be added to the parameters form.
Sure, but to reiterate my question from above: How do you populate the "manually select parameters" list? If we use Parameter.switchable
that is probably fine. If not, what is your plan?
We can chat in person today!
The plan was to populate the manually selected parameters list by just grabbing all domain types in the task graph (upstream from the target outputs).
But yeah using Parameter.switchable
is of course another option.
Unfortunately I'm WFH today, but we can huddle.
The plan was to populate the manually selected parameters list by just grabbing all domain types in the task graph (upstream from the target outputs).
Then please reread my original comment on why that is not a solution: https://github.com/scipp/essreduce/issues/74#issuecomment-2286095005. If you just grad "all domain types" you loose this self-documenting/self-explanatory part of the UI (and are left with something that is little better than just using Python to set parameters on a workflow).
This is getting pretty confused so I think it's better we talk directly.
As I see it this issue is not about how to populate the parameters list. It's about having a multiple -select instead of a checkbox next to each (selectable) parameter in the form.
I was thinking we just to have one big list, but really, how to determine what parameters are selectable or not seems orthogonal to the question in the issue.
Notes from discussion:
Parameter.switchable
)Example:
A->B->C->D
Current
Switchable
widget is a check box that shows the underlying widget when it's selected.@jokasimr suggested different way of handling parameter
switch
.Instead of setting
switchable
to all the parameters, we can treat all parametersswitchable
, and have a menu ofparameter
from the workflow, just like we select output.And if the
parameter
is selected, it should show the widget on the right side and the workflow-running widget should set the parameters.Here is the conceptual drawing how it can look like: