[widget Audit] toga.SplitContainer

[freakboy3742]

Audit of SplitContainer.

Builds on #1969 because of the changes to root containers on Cocoa.

Removes support for more than 2 panels of splitpanel content; Cocoa was the only platform that had any support for this.

Removes support for a configuration option that allowed a panel in a layout to have fixed size. This seemed exceedingly fragile in implementation, had some interesting interactions with Pack, and (AFAICT) wasn't implemented as documented on any platform.

There's one piece of platform behavior that is undefined: if you have a split container and change the direction of the split, the position of the split after the orientation change is undefined. I was borderline on whether this API should be removed entirely - changing split direction seemed like a niche use case.

Explicitly not implemented on Android and iOS because a split panel isn't a native concept on those platforms.

Audit checklist

• Core tests ported to pytest
• Core tests at 100% coverage
• Core docstrings complete, and in Sphinx format
• Documentation complete and consistently formatted
• cocoa backend at 100% coverage
• winforms backend at 100% coverage
• gtk backend at 100% coverage
• iOS backend at 100% coverage
• android backend at 100% coverage
• Widget support table updated
• Widget Issue backlog reviewed

[mhsmith]

I tried using a type alias along with autodoc_type_aliases, but that resulted in types becoming unlinked or even disappearing from the docs completely.

[freakboy3742]

Yeah - I've haven't been 100% happy with how these non-trivial type annotations are rendered, but type aliases just seems to make it worse in every variation I've tried.

[mhsmith]

I'm not sure whether this code is properly verified by the testbed, and it isn't easy to test manually until minimum window size is working. So maybe any further work in this area should be deferred until #2020. However, I have a couple of comments:

• This code is very similar between Cocoa and GTK, so it should be factored out into a function in the interface layer.

• Also, I see that the GTK version calls recompute to update min_width and min_height, but I don't see any equivalent in Cocoa. Doesn't that mean that it'll always use the minimum size stored in set_content, which won't reflect any later internal changes to the content?

[freakboy3742]

Agreed there's a lot of similarity here; AFAIR, the discrepancy is because of GTK's "deferred" layout scheme. In Cocoa, by the time rehint() has been called, we know content has been added and Pack has been called to update minimum sizes; on GTK, Pack isn't invoked until the layout is actually underway, and it's done "top down" in the layout tree, so the layout of the children of the splitter haven't necessarily been computed yet.

I'm fairly sure you're also right that this will fall apart in the cases that #2020 fixes - i.e., the case where the root content of the split containers doesn't change, but there is a layout altering change in that content that changes the minimum.

There is a test for enforcing minimum sizes on containers, but it's probably not as thorough as it could be - it needs to:

• explicitly check the case where the sub-container is > and < MIN in the given axis - the current test only validates "can't make the splitter smaller than the minimum"; and
• check the case where the layout of the sub-container is altered without changing the root widget that is associated with the split container.

The second case can't really be checked until #2020; so I agree it makes sense to defer until then.

[mhsmith]

OK, I've added a link to this discussion to #2020.

[freakboy3742]

I marked this as xfail because I can't think of any meaningful analog of a SplitContainer view on mobile, so SplitContainer is "not implemented on purpose", rather than "not implemented yet". Have you got something in mind for SplitContainer?

[mhsmith]

OK, that makes sense. I've changed it back to xfail and added some comments to explain the difference.