Viewport-Control widget: Limit width to at least dynamic minimum size of widget. Add tab order back in. Fixes #5116

[haikusw]

Addresses #5116 - Viewport-Control widget can be made too narrow & tab order was lost is now weird.

PR #5107 improved the Viewport-Control widget by allowing it to morph to a vertical layout when the widget became too narrow for the original horizontal layout. Very nice!

However, after that change the widget could be made too narrow and look bad because the controls were "cut off" and only partially visible. #5107 also lost the left-to-right top-to-bottom tab order within the widget. This PR fixes both of these issues. See #5116 for screenshots and detailed steps.

[t-paul]

Thanks for the tab fixes. Forcing fixed sizes on the scollarea has shown all sorts of funny effect, I'll try if that works without surprises.
Also I'm not sure it's actually better to enforce this. Sometimes it might be easier to just move the window out of the way even though it's clipping instead of closing it completely. But I'm not too focused on one solution, so if it works, we can go with it.

[haikusw]

Thanks. I tried to keep it to a very focused fix.

I tested as much as I can on a mac. Tried moving the widget to other places in the window and combining it with other widgets in the same area; it all seems to work without any weirdness. I don't have other platforms to test on though, so that would be my main concern.

One possible change, now that you've pointed out there may be issues with oddities relating to fixed sizes and scrollarea, could be to rest the minimum to none when switching back to the horizontal layout. I did not see any issues in my testing, but if you see any I'd be happy to add this change.

I think cutting off controls looks pretty bad. Since all, or nearly all, of the other wedges prevent this from happening it seems best to be consistent.

Since you fixed the main issue of having a minimum width that was very wide (thanks!) it won't get in the way nearly as much.

[haikusw]

Thought I might add that I initially put in a hard-coded empirically determined minimum width to prove the approach of setting the minimum to fix this would work (it worked). For the final implementation I use a dynamically calculated minimum (scrollAreaWidgetContents->minimumSizeHint().width()) to support potential cross platform control/font/widget sizing differences (including accessibility settings the user may have chosen to increase font size, etc).

[t-paul]

I'm not sure why, but it does not seem to make a difference on Linux (using the AppImage build).

[haikusw]

Weird. Since it's unlikely (?) that Qt behaves differently on Linux, my first thought is that the build didn't actually rebuild it, or didn't use the right branch or something.

I'm not sure what "the AppImage build" means but I'll take a look and maybe spin up an Ubuntu VM and see how difficult it is to get it building there.

[t-paul]

AppImage build in this case refers to the automatically built one which can be found via the green checkmark on the commit.

This should always build on a clean system.

I'll try to find time to check locally too, maybe adding some temporary debug output for actual values. While the general behavior of the widgets should be mostly same on platforms, there's potential for small differences in regard to specific values and/or event ordering.

[haikusw]

I created a new Ubuntu 20.04.2 ARM64 VM, slogged through updating it enough to build openscad, and built the branch haikusw:viewport-control-layout-minwidth and I see the same thing you do - no change to prevent viewport-control pane able to become too narrow to fit in the window.

I'll see if I can get setup to debug code on Ubuntu; not something I have a lot of experience with.

[t-paul]

It does not seem to do any harm and at least works on one platform. So I'd say lets get this state merged and also get the tab order fix. If we find a cross platform solution, we can always use another PR based on this.

[haikusw]

Thanks. I almost got VS Code to debug the project on Ubuntu last night but not quite (builds and launches it, but no debugging). I'll try again when I get a chance and see if I can't track down what's different on linux.