PICARD-2791: Prevent panes of options window being fully collapsible

[phw]

Summary

• This is a…
  • Bug fix
  • Feature addition
  • Refactoring
  • Minor / simple change (like a typo)
  • Other
• Describe this change in 1-2 sentences:

Problem

• JIRA ticket (optional): PICARD-2791

Prevents users accidentally hiding a pane without knowing how to get it back.

Solution

Set setChildrenCollapsible on the splitter and minimum widths for the panes. Very similar to what was done in #1634 for the main window panes.

[phw]

@zas: I'll adjust this patch for the 2.10.x branch after it got merged.

Also can you test this in the options? For me with Qt6 resizing the panes is extremely laggy. Works well in Qt5. No such issue in the main view.

[zas]

Also can you test this in the options? For me with Qt6 resizing the panes is extremely laggy. Works well in Qt5. No such issue in the main view.

I tested and it's a bit laggy to me too, but I noticed a possible reason:

• without the patch, resizing hide existing widgets pixel per pixel

Moving the central bar to the right leads to:

• with it, resizing hide the widget in whole at once

If you move the central bar to the right as above, texts & buttons suddenly disappear:

[phw]

If you move the central bar to the right as above, texts & buttons suddenly disappear:

That is actually what is supposed to be prevented by setChildrenCollapsible(False). Can you test with a fresh config? We probably need to reset the persisted splitter state as we did in #1634

If setChildrenCollapsible(True) then the behavior you describe is expected if there are min sizes for the panes. You can resize freely in the size boundaries or hide completely.

In any way, this seems to be all unrelated to the sluggish behavior, as this is the same either way (and not present in Qt5). I rather suspect that some drawing or layout calculation performance is worse, and resizing this particular view has to recalculate the layout of all the different option pages. This seems to be the case, as you for example cannot resize beyond a certain size if it is prevented by the layout of any specific page.

[zas]

Can you test with a fresh config? We probably need to reset the persisted splitter state as we did in #1634

Yes, that's it, I removed splitters_OptionsDialog and it works as expected.
You are right, that's unrelated to sluggish behavior (here that's quick enough). Can it be related to your Qt acceleration settings (OpenGL or whatever)?

[phw]

@zas I added a config upgrade hook to clear splitters_OptionsDialog

[zas]

LGTM