Only one plot is allowed for all open fit tabs

[butler]

In the process of testing for ticket #1099 I discovered that if more that one fit tab is active all tabs updated the plot for the last tab opened, leaving the original plots effectively orphaned.

Notes:

1. The residual plots appear to behave as expected (the original residual plots continue to update)
2. Theory tabs (i.e. before a data set is sent to a particular tab) do not appear to count as fit tabs. If several "theory" tabs have been opened after the last fit, all fits still update the plot from the last fit tab.

[krzywon]

This is only true when a single data set is sent to multiple fit tabs. All other fits remain linked to their respective plot. Looking at the code, when a data set is plotted, the plot is linked to the data set in the data manager window. When the data is plotted a second time the original plot is overwritten in the data manager. Fitting uses the data plot in the data manager, and does not store its own plot reference, causing this issue.

I started these tests using the code in master, but as a secondary check, I loaded SasView? v4.1.2 and v3.1.2. Both versions act the same as master. Considering how long this has gone unnoticed, I would suggest this not be a blocker.

[butler]

Actually 4.2 does introduce another layer of bug, but it is more subtle than described so far. It does however apply only to the same data set being sent to several fitpages.

1. It indeed appears that built in models in fact behave the same across all 3 versions described. However these are NOT orphaned as originally described. What actually happens in this case is that BOTH plots (the plot attached to the original fitpage as well as the last fitpage with the same data set) get updated.
2. However, in 4.2, the update of the first fitpage requires a second "fit" or "compute" button to be pressed.
3. The big difference however it that plugin models (4.2) behave differently in that, in that case, the plot associated with the first fitpage does appear to be completely orphaned with no updates ever going to it. This does not appear to be the case for "customized models" in 3.1.2 for example.

Nonetheless these are less severe than originally thought and can probably be pushed to 4.3 if necessary.

[tcbennun]

In the latest 4.2.0 version from git, I'm seeing that if you send the same data set to multiple fit pages, and choose any model (built-in or not), only the most recently created plot is ever updated, including when I click 'fit' or 'compute' on any of the fit pages. The plots created before are entirely static and unused.

In the latest ESS_GUI (QT5) version from git, I find the following, if the same data set is on multiple fit pages (using built-in models so far):

1. The data set itself (not the model curves) is only ever plotted on the plot associated with the first fit page.
2. When the second fit page is added, and the model selected, the first plot is blanked, initially. Only the model curve appears on the new plot.
3. When a third fit page (and so on) is added, the first fit page's plot is recovered.
4. Clicking 'show plot' on any fit page will cause subsequent fit pages' plots to blank. Previous plots are unaffected.
5. Destroying a fit page and associated plots does not remove the model curve data. Subsequently created fit pages' plots will show curves from deleted fit pages, and they seem to be permanent!

Apologies, there's a lot there…

[butler]

This is interesting. I have downloaded the latest 4.2 build (#369 from 28 June) on another windows 10 PC and I find mostly what I found originally with some quirks (with respect to builtin models). Sometimes I needed to place the cursor in a parameter box and hit return before the first page updates (hitting compute or fit indeed did not work). This may be a case of difference between installable version versus locally built versions?

However, this time I find that plugins, including 4.2 types, seem to behave similarly to built ins (as they should). Hopefully this speaks to poor testing/reporting and confusion of exactly what the problem is and does not reflect an unstable product? …

[butler]

This is a rather specific situation that doesn't seem to be encountered very often. Moreover any fix could easily cause unintended consequences in other parts of the GUI code so would be dangerous to try to fix now. Finally, depending on how quickly we can get 5.0 and the GUI out, our limited resources may be better spent fixing it in 5.0 rather than 4.x.

This should however be listed as a known issue in the 4.2 release notes