Fix unusable legend size with long filenames on Mac

[pbeaucage]

As described in #1337; the fix from @krzywon both works on Mac and dramatically simplifies the legend code. I'll test on Windows shortly.

[pbeaucage]

This is working on Windows as well, and while the behavior with long datanames is a little wacky, it is usable.

[pbeaucage]

I added text-wrapping and a floating legend width; these combine to make this a fairly robust fix for #1337. Unfortunately some plot geometries still have the issue but they are largely when the plot is tiny. Making the legend fixed- and full-width by using , mode='expand') when creating it fixes the issue reliably but looks bad, see above. Maybe we could make this a user preference?

[gonzalezma]

It does what it says, but with very long titles the legend can still become annoying, e.g.

What about "cutting" the title, at the price of losing information in the legend, e.g.

[rozyczko]

Miguel's suggestion is good, I would go even further - have names with ellipsis by default but expand them fully when the cursor hovers over the legend (or on click?).

[pbeaucage]

I'll point out that this PR really was intended to have a quite narrow scope: the point of #1337 and thus this PR was to fix a font scaling issue that has made sasview 5 unusable on macs with certain hard-to-define, but fairly common monitor configurations for the last 3.5 years because the plot legends look like this:

or

with no workarounds, not even hiding the legend (which only started working properly in #2266 yesterday).

So I would suggest that building a real solution for arbitrary length filename display is a larger-scale problem that shouldn't necessarily block merging this patch PR for a longstanding issue that critically impacts usability.

that said,
In general, I feel like truncating the user's input is a fairly problematic thing to do. Presumably they used a long name for a reason and if the plot legend is a little unwieldy (I point out that Miguel's demo above, while a bit ugly, is still usable which the current solution is not). Given that (a) we provide users with GUI tools to rename data if they wish, (b) users can rename their own files out on the filesystem, and (c) there is robust tooling in shells on every OS we support to do this renaming programmatically for users with large numbers of datasets, I don't see a good reason to override what the user has told us to call their data. If it's unusable because of user input, and we provide the user with the tools to make it usable, what are we to do? You can only shield the novice user from their own incompetence so much before you start preventing power-users from doing what they want to do.

With the expand-on-hover / expand-on-click solution it becomes (a) tedious to hover/click each item, (b) difficult to save a plot with a complete legend for further re-use in another context.

I can see having 3 config parameters to let users really control this behavior:

FITTING_PLOT_FULL_WIDTH_LEGENDS default False, if True invokes the plt.Legend command with mode='Expand' so that the legend is always full-width and very little dynamic rescaling is performed; this will as far as I can tell always work but truncates legends at screen width and looks ugly. Basically a debug setting should this fix turn out to fail in the wild.
FITTING_PLOT_LEGEND_TRUNCATE default False, if True truncates everything except the first and last (FITTING_PLOT_LEGEND_MAX_LENGTH/2 - 2) of the legend label and inserts .. in the center before display such that each legend line is a single line, basically Miguel's solution
FITTING_PLOT_LEGEND_MAX_LINE_LENGTH default 30, sets the text-wrap length or the truncation length depending on FITTING_PLOT_LEGEND_TRUNCATE, basically Wojciech's proposed parameter

Is this too many config parameters to add? or about the right level of flexibility?

[pbeaucage]

OK, added the config items as above. The result looks pretty good! With max line length of 30 and truncate on:

Same, truncate off:

[pbeaucage]

Moving the preference panel GUI to a different branch/PR as it depends on updated tooling from @krzywon

[pbeaucage]

This should now be ready for final review if tests pass.