Hint ScrollContainers properly in non-scrolling directions

[johnzhou721]

Describe the bug

On all platforms, when the content of a ScrollContainer has a minimum size in a non-scrollable direction (e.g. a widget with minimum width as the content of a horizontally non-scrollable ScrollContainer), the ScrollContainer is still allowed to shrink in the nonscrollable axis beyond a size necessary to present the content.

How to reproduce the bug

1. Run the example code
2. See how you can shrink the window beyond 500px which is the minimum size of the content.

Minimum example code

import toga
from toga.style import Pack
from toga.style.pack import COLUMN


class ScrollTest(toga.App):
    def startup(self):
        content = toga.Box()
        content.width = 500
        content.background_color = "magenta"

        scroll = toga.ScrollContainer(
            horizontal=False,  # disable horizontal scrolling
            vertical=True,
            content=content,
            style=Pack(flex=1),
        )

        self.main_window = toga.MainWindow(title=self.formal_name)
        self.main_window.content = scroll
        self.main_window.show()
ScrollTest('1', '2.3').main_loop()

Screenshots

Shrinked window:

Actual minimum size of content:

Environment details

• Operating system and version: macOS 26.3.1
• Python version: Python 3.13.0
• Software versions:
  • Toga: e9cdbdb

Logs

No response

Additional context

I believe that the fix will be in the rehint() of each backend.

The two different scrollbars will interact with the minimum sizing, so that must be handled properly.

On macOS, opaque scrollbars may be shown at all times through a setting, which can be changed at runtime; that must be handled appropriately, even though macOS usually uses a translucent scrollbar.

[freakboy3742]

Agreed the layout of your specific example isn't great - however, I'm not convinced a bug. I think the situation you've highlighted is one where the problem is ill defined. Some layouts are always going to be bad; I think this is one of them.

The purpose of a scroll container is to decouple the size of the internal content from the size of the scroll container itself. The question at the core of this report is whether it's the ScrollContainer's responsibility to enforce a minimum size based on inner content size when it knows it can't scroll in that direction.

The catch is that there's already a size relationship going the other direction. In your example, the inner content has an explicitly defined fixed width; but what happens when the size of the content is flexible? Right now, the width of the scroll container is passed down to the child content as part of the hinting process, and content will be laid out on to fit the available size. If the ScrollContainer also has to adapt to the size of the content... which size hint goes first? What happens when the initial size of the container forces a layout that causes the scroll container to change size, which causes the content to change size, which causes the scroll container to change size,...

I'm going to close this ticket on that basis; if you can present a good counterargument (and algorithm for resolving the edge case I've described), I'm happy to re-open.

[johnzhou721]

The catch is that there's already a size relationship going the other direction. In your example, the inner content has an explicitly defined fixed width; but what happens when the size of the content is flexible? Right now, the width of the scroll container is passed down to the child content as part of the hinting process, and content will be laid out on to fit the available size. If the ScrollContainer also has to adapt to the size of the content... which size hint goes first? What happens when the initial size of the container forces a layout that causes the scroll container to change size, which causes the content to change size, which causes the scroll container to change size,...

I agree the actual size will change, but I'm not sure if I quite follow what you're thinking. Just to be clear, I was talking about the minimum size of the content. The minimum size of the content container should stay fixed across all layouts; so in my opinion, this would be what will happen:

1. When a ScrollContainer is refreshed, its content is also refreshed; a minimum size of the content container results from this pass.
2. ScrollContainer logic computes the appropriate minimum size of the ScrollContainer, accounting for scrollbars. The ScrollContainer is rehinted with that minimum size, and triggers a refresh across the whole window/scaffold's container to account for it.
3. The inner content is re-sized, but the minimum size of it shouldn't change this time; this time, the ScrollContainer again recomputes its minimum size, but finds that it is identical to the minimum size hint already provided to core. Thus, no refresh is needed for now.

Did I miss something in my logic here?

[freakboy3742]

Did I miss something in my logic here?

I guess if it's constrained to only dealing with minimum sizes, it could be tractable - as you say, the minimum size of content is independent of the window or widget size, so there shouldn't be any "recursive" possibilities here.

I suppose this is analogous to what already happens with Window, OptionContainer and SplitContainer - when content of a container is refreshed, the min width and height for the container is updated. This would essentially be applying the same feedback mechanism on ScrollContainer, but setting the minimum bounds of the layout hint for the ScrollContainer itself, rather than the container. Scroll container is the odd-one-out here in that it is the only Container class that doesn't have any response to the minimum size of content. The exact ordering of sizing requests will matter (especially if we want to minimize the number of layout computations); but I think I can see how it would work, and I agree it would be consistent to do so.

My follow on question for that would be how that should be interpreted when the ScrollContainer is scrollable - I presume you'd suggest the layout minimum size should be set to the current "widget minimum" (i.e., 100px)?

Regardless, I think I may have been premature in closing this; reopening on the basis that I now agree that there's a discrepancy here.

[johnzhou721]

My follow on question for that would be how that should be interpreted when the ScrollContainer is scrollable - I presume you'd suggest the layout minimum size should be set to the current "widget minimum" (i.e., 100px)?

Yes, this would be the interpretation.

It's also worth noting that we'd need to update the minimum size if scrollbars are reshown/hidden in set_bounds, and trigger another refresh if neccessary as scrollbar showing and hiding can impact the other axis.

Regardless, I think I may have been premature in closing this; reopening on the basis that I now agree that there's a discrepancy here.

No worries, thanks for following up on this!