Adapting to Liquid Glass in terms of layout

[johnzhou721]

[note: Images below are only numbered if they are referred to. Thanks for @mhsmith for guidance to migrate this to GitHub instead of Discord to keep better record.]

Since Liquid Glass (new iOS and macOS 26 design) adaptation was mentioned as finnessing for a proposed new sidebar recently, I'd like to share some research I've done for Liquid Glass layout-wise in general. Take tab bars (OptionContainer) on iOS as an example. The scroll view as the content of the tab bar seems to fade into the tabs, as seen below:

But an equivalent structure with a tabbed container with a content of a scrollcontainer done by Toga, as seen here:

Screenshot 2

, has the bottom portion obscured. To fix this, line 57 of OptionContainer on iOS must be removed for iOS >= 26 according to this StackOverflow question -- and removing that, the results are here (top to bottom):

Screenshot 3

Screenshot 4

But if you change the content inside the tab to be a vertical box with a scrollview and label at the bottom, the result becomes this. where the text is at the bottom edge of the screen.

Screenshot 5

Indeed, the content of the tabbed view has bounds that will be obscured by the tabs with this new design; however, it has a "safe area", which is the unobscured portion which we should be doing layout with -- but with the caveat that if we do all layout within the safe area, the initial problem presented (the structure in Screenshots 2 & 3) will be displayed as Screenshot 2, because the scroll view does not take up the whole container physically (Note that I have changed the code of Toga to prove that it's exactly the same as screenshot 2, except for like a tiny margin of a few pixels somewhere on the top). Scroll views, unlike regular content, can and should extend beyond safe area when appropriate; safe areas will inherit (what is unsafe in the parent is still unsafe in children), and the scroll view will utilize that safe area to determine when the end of a scroll should be and position its content appropriately, which is what is demonstrated in screenshots 4 and below, which is the configuration in Screenshot 5 scrolled to the bottom:

So to summarize; for regular content layout must be performed within the safe area, but the layout must be extended beyond the safe area for scrollviews when appropriate. Native apps do not have this problem at all, as the scroll view is directly the content of the tab view, and it does not need to be manually positioned.

Another heads up as well: We'll hit another instnace of such problems in macOS and iPadOS when we start to add sidebars. Take the following, from the TV app on macOS:

The horizontal scroll must be manually positioned beyond the safe area (for similar reasons as the tabview example), but the other elements, like the "About" heading, must be positioned in the safe area (all this is if automaticallyAdjustSafeAreaInsets is enabled.). How margins, etc. will be influencing all this is going to be a big problem.

So I want to start a discussion about all this: Since only select elements should be extending into safe area insets, how will we determine when and how to do so in Toga? For example, an option would be to let the content of a tabbed container leak into the safe area insets whenever there's one scroll view only inside the option container, and for all scroll views to go beyond safe area in a sidebar. Any other thoughts on how to do layout with all of these things considered in general?

[freakboy3742]

So I want to start a discussion about all this: Since only select elements should be extending into safe area insets, how will we determine when and how to do so in Toga? For example, an option would be to let the content of a tabbed container leak into the safe area insets whenever there's one scroll view only inside the option container, and for all scroll views to go beyond safe area in a sidebar. Any other thoughts on how to do layout with all of these things considered in general?

Thanks for that research - that's all very helpful.

I think there's an existing concept in Toga that we can use/adapt here. A few releases back (iOS 15?) the title bar was made translucent by default. The introduction of that change had a very similar effect to what you've described here, but at the top of the screen - without an explicit offset, main container content would be obscured. That required us to make an accomodation in the BaseContainer allowing for a top offset - when the constraints for a widget are set positioned, the "top offset" is considered - and the top offset is set based on the size of the top navigation bar. That means that the main window content has an enforced padding at the top of the box; the window will still scroll, but there can't be any active content under the titlebar in the initial screen position.

I think the same may be necessary here. In addition to the transparency fix that you identified, content in an OptionContainer needs to have a "bottom offset" that allows for the size of the selection bar. That would ensures the label in your example is just above the option bar in the "scrolled to the bottom of the page" configuration. A similar approach with a left- or leading-offset would work for the sidebar problem you've flagged.

[johnzhou721]

@freakboy3742 Understood. We'd need to perform all layout with the "safe area" -- which automatically accomodates for all of those things as far as I know. However, computing container height sort of gone astray if I just use the safe area---not sure why the top_offset still needs to be added.

But my point is that this is probably easy to do (with a lot of debugging); however, the hard part is that if we lay out all content within said bounds, making sure that the bottom offset is accoutned for, we can't achieve the scrolling effect with bottom blurred and glass on top. Why? Because we need to place the scrollview outside the usual bounds right into the bottom tabbar, and the scrollview itself will auto-accomodate for the bottom area. So the problem becomes: when do we place things beyond the safe area? I'm guessing a useful heuristic would be in set_bounds if the current item is a scrollview and any top/left/down/right distances to parents is 0, then extend into unsafe area. But not sure if this would be wrong in some edge cases...

But you're right, let's get the transparency fix and safe area layout done first.

[freakboy3742]

Ah - I missed the subtlety of the interaction there.

I don't know that I have a good answer for this off the top of my head; the best option I can think of is to make a special case of the ScrollContainer widget (or, more likely come up with some sort of flag that could be put on any widget) that describes that it will accommodate the extra scroll distance needed to be visible.

The other option would be to dig into how iOS intends this sort of thing to be represented. Presumably this is a situation they've documented in some way - the setup you've described isn't that unusual.