Opened 6 years ago
Last modified 6 years ago
#1135 new defect
QT GUI - complex constraints (master ticket)
Reported by: | tcbennun | Owned by: | tcbennun |
---|---|---|---|
Priority: | blocker | Milestone: | SasView 5.0.0 |
Component: | SasView | Keywords: | |
Cc: | piotr, wojciech, richardh | Work Package: | Beta Approximation Project |
Description
In the QT GUI, there are some issues with the complex constraints functionality.
- Activating the complex constraints dialog is only possible by selecting multiple fit pages in a special table before right-clicking to bring up a context menu.
- The dialog has a text box for editing constraints, but it breaks when using multiple parameters on the right-hand side.
- The dialog does not allow you to select which models to take fitting parameters from; it is fixed to whichever two fit pages were selected prior to activating the dialog.
Possible solutions to the above problems are, respectively:
- Add a simple button labelled "Add Constraint" or similar.
- Fix the text box!
- Add combo boxes (drop-downs) for the left- and right-hand sides of the constraint, to allow a model to be chosen before choosing a parameter from that model.
I have some agreement with Richard and Piotr on this, so far, and will add updates to this ticket in the next few days.
(I'm putting this in the beta approx. work package but feel free to move it, I'm not sure where it should go…!)
Change History (8)
comment:1 follow-up: ↓ 3 Changed 6 years ago by piotr
comment:2 Changed 6 years ago by tcbennun
- Milestone changed from SasView 4.2.0 to SasView 5.0.0
comment:3 in reply to: ↑ 1 ; follow-up: ↓ 4 Changed 6 years ago by tcbennun
Replying to piotr:
Issues 2. and 3. are both based on the initial decision to support two models for intermodel constraints.
If the requirement is to include more than 2 models in the complex constraint functionality, the design will have to be redone.
I agree with 1., as discussed with Torin elsewhere.
For 3. it still only uses 2 models, it would just be nice to have a 'generic' dialog box in which you can select the 2 models you want to use.
Re issue 2., even if you use 2 parameters from the same model on the right-hand side it breaks, e.g. {{M1.radius < M2.radius + M2.thickness}} is invalid, even though parameters from only 2 models are being used.
comment:4 in reply to: ↑ 3 Changed 6 years ago by piotr
Replying to tcbennun:
For 3. it still only uses 2 models, it would just be nice to have a 'generic' dialog box in which you can select the 2 models you want to use.
Hmm One potential scenario this could be useful is when there are many model pages displayed and the user wants to navigate between them without having to ctrl-click in the list potentially making mistakes by mis-clicking.
Maybe then the solution would be to use just one widget which would have a checkbox for using selected model pages (if 2 selected) vs using combo boxes as you described above?
So for any other selection you would have a dialog with only:
<model 1 combo> <param 1 combo> <operand> <model 2 combo> <param 2 combo>
with the checkbox disabled.
For 2 selected models you would have the above, when the checkbox is off and the current setup when the checkbox is on
<model 1 label> <param 1 combo> <operand combo> <model 2 label> <param 2 combo>
This is much less confusing than separate dialogs with different content.
Re issue 2., even if you use 2 parameters from the same model on the right-hand side it breaks, e.g. M1.radius < M2.radius + M2.thickness is invalid, even though parameters from only 2 models are being used.
Again, wrong initial assumption on what the requirements were. Yes - this needs to be fixed.
comment:5 follow-up: ↓ 6 Changed 6 years ago by tcbennun
Sounds good!
This is kinda just details, but I was also thinking that the ctrl-click interface is possibly a little unnecessary. Maybe simply clicking a fit page in the list could select it, while retaining the previous selection. (Also might be necessary to forcibly limit the number of selected fit pages to two, i.e. if two are already selected, selecting another one would automatically deselect the 'oldest' selected page. Currently if you select more than two fit pages, the dialog simply doesn't appear.)
comment:6 in reply to: ↑ 5 ; follow-up: ↓ 7 Changed 6 years ago by piotr
Replying to tcbennun:
Sounds good!
Also might be necessary to forcibly limit the number of selected fit pages to two, i.e. if two are already selected, selecting another one would automatically deselect the 'oldest' selected page.
I would like to retain multiple selections for the "Select/deselect pages for fitting" functionality.
The additional button discussed earlier (for defining constraints) would get enabled only when two pages were selected and a tooltip over the button could explain its enablement criteria.
comment:7 in reply to: ↑ 6 Changed 6 years ago by tcbennun
Replying to piotr:
I would like to retain multiple selections for the "Select/deselect pages for fitting" functionality.
The additional button discussed earlier (for defining constraints) would get enabled only when two pages were selected and a tooltip over the button could explain its enablement criteria.
Ahh, I see now, thanks!
comment:8 Changed 6 years ago by richardh
OK to summarise, there are two functionalities which both involve selecting Fitpages, which both have to be obvious to the user:
(a) which of possibly many Fitpages are to be included in the simultaneous fit when they hit the Fit button on the simultaneous fit tab.
(b) which two fitpages are involved in a constraint that a user wants to set up. [ Note, due to horrible issues with polydispersity integrals we do not allow a constraint within a single Fitpage, and suggest instead that the user writes a custom version of the model to acheive this.]
Personally I like the idea that by use of drop downs etc an equation appears in an editable box e.g.
M1.radius < M2.radius + M2.thickness
which can then be further customised by the user e.g to become
M1.radius < 0.75*M2.radius + 3.0*M2.thickness
with an "OK" or "add this constraint" button when finished editing.
[Note, suspect inequality constraints need some further work in fitting engines, so should not actually appear in 5.0, see #426]
Issues 2. and 3. are both based on the initial decision to support two models for intermodel constraints.
If the requirement is to include more than 2 models in the complex constraint functionality, the design will have to be redone.
I agree with 1., as discussed with Torin elsewhere.