OptionContainers in Toga in regards to usage in small sections vs. top-level structure

[johnzhou721]

Toga needs to represent in some way top-level navigation of multiple distinct parts of the app, aka. a bottom bar, and related but separate nonsequential content in one part / area of the app.

The distinction is that the top-level navigation optioncontainers are usually placed as a bigger bar on the bottom of the window, but the option containers for navigation in small sections has a tab chrome and some kind of frame instead of a just a bar.

---

As a concrete example before I get to specific examples, here's a mockup where the OptionContainer is used in a small section of the application:

On the other hand, if the same kind of styling for hte OptionContainer is used to represent distinct parts of the app as a top-level structure, it would look like this:

which would look kind of jarring because there's already a window frame, and the options have another frame. But if we instead do this:

or this:

it would look much better.

---

Multiple distinct parts of the app as top-level navigation form:

macOS clock app:

iOS News app:

KDE Alligator:

GNOME NewsFlash:

Android bottom layout (current impl in Toga):

---

Navigation between related options in a specific part of the app:

iOS -- mail app when searching, all/current mailbox options can display differnet content:

Android -- example from Material Design 3 guidelines -- the tabs are in a specific area rather than top-level of the app:

macOS -- Toga Demo -- tabs are specific to left part of app:

Qt:

Winforms:

[freakboy3742]

I think I can see the sort of distinction you're making here.

My immediate question: Have you identified different widget, or different ways to render the same widget? Are all of these OptionContainer - but if OptionContainer is the content of a MainWindow on macOS, it's rendered like the world clock example. If it's the content of a SplitContainer, it's rendered Gnome NewsFlash; otherwise, it's the "tabs" as currently defined. Whether any of these alternatives are possible at all will depend on what any given platform provides - the current "tab" implementation works; but we can enhance it over time if there are other options.

However, the meta-question I'd like to pose before we dive too deeply: Does this matter?

Toga is, ultimately, a cross-platform GUI abstraction framework, and all abstractions leak. It will not be possible to define all apps that might be possible on any single platform. And that's OK. We should aspire to make as many apps possible as possible; but just because something is possible on one specific platform doesn't mean we have to wrap it - certainly not at this point in Toga's development where there is a lot of much bigger fish to fry.

Issues like settings management, login workflows, and navigation control strike me as much more significant problems to resolve right now, because there are specific applications that can't (or can't easily) be built. Unless there's a specific use case motivating this for you, I'd suggest that those more foundational problems should be our focus, rather than trying to solve problems that we don't actually have because the theoretically exist.

[johnzhou721]

@freakboy3742

One of the specific usecases motivating this is Liquid Glass adaptation on iOS. As mentioned in the other thread... we have to directly do UIWindow > UITabBarController; if we add UITabBarController.view as a subview of a UIView in a UIWindow (either in Toga/Python or natively), when you make some adjustments to the frame of the view for purposes like liquid glass, things start breaking and requires really ugly hacks for things work properly.

UITabBarController, I have concluded after some experimentation, should be directly attached to UIWindow for things to work properly. #3957 also proves the fragility of having UITabBarController be a widget attached to a container, rather than directly to the window. And if we still make OptionContainer wrapping UITabBarController as a Widget... I'm not sure how we're going to be able to modify the window hierarchy to hack in a UITabBarController, and then there's the question of how to manage layout when there's other items on the screen.

(My latest comment at #785 should be similar in tone to the above paragraph, and the reasoning is similar)

In other words, this isn't about a separate widget, this should be a question of if it's managed as a top-level navigation structure on MainWindow or if it's a widget. If we figure we don't need this to be a top-level navigation structure, then I agree keeping the current widget is fine.

To be explicit -- by a structure, I mean some kind of set of methods on MainWindow that manage content for multiple tabs.

I agree there's bigger fish to try like #785, however if we do decide that a structure on MainWindow is neccessary, #785 will be directly impacted by this. So I'm trying to get the discussion out right now -- in my opinion, structure on MainWindow may imply some complicated code, but longer-term a lot more maintainability.

[freakboy3742]

@freakboy3742

One of the specific usecases motivating this is Liquid Glass adaptation on iOS. As mentioned in the other thread... we have to directly do UIWindow > UITabBarController; if we add UITabBarController.view as a subview of a UIView in a UIWindow (either in Toga/Python or natively), when you make some adjustments to the frame of the view for purposes like liquid glass, things start breaking and requires really ugly hacks for things work properly.

FWIW - it wasn't at all clear to me that this is the point you've been trying to make. This sounds like a very real, very actionable concern; more importantly, it seems like an internal architectural thing we need to get straight as part of #785, and any other large-scale app navigation concern.

So: In an "ideal, pure iOS API" case, what is the suggested object ownership structure that does work for Liquid Glass? My understanding was that Controllers were almost completely orthogonal to Views - A controller has a root view, and the purpose of the Controller was to then maintain the contents of that view, but the controllers didn't need to be specifically bound to anything, outside of the need of a Window having a root view controller so that top level app management stuff can happen.

If that's not the case, then sure - we'll need to make some changes here, and the interaction with OptionContainer and NavigationController will be critical.

[johnzhou721]

@freakboy3742

FWIW -- I apologize that I was not being clear with the point. But with regular OptionContainers, this is not a concern; only the tab bar representation of it is, so I was suggesting to abstract this out fundamentally so we can get things like this done. I'm sorry if this became an Xy problem.]

When I said controller in the last message, I meant the view of that controller.

So... the suggested way to work this is using UIWindow.rootViewController = tabBarController, and tabBarController. viewControllers = [UINavigationController, UINavigationController, UINavigationController...]

If you happen to change toga_iOS to make top_offset 0, then the tab bar placement will start breaking on iOS18 (which is not even Liquid Glass) and is not easily fixable.

[Sidenote: tab bar as a window structure may mean that a sidebar (if we do it later)) and a tabbar cannot be on a window at the same time, because different platforms has different ideas about what these interactions look like, and in android and maybe iOS they're mutually exclusive.]

[freakboy3742]

@freakboy3742

FWIW -- I apologize that I was not being clear with the point. But with regular OptionContainers, this is not a concern; only the tab bar representation of it is, so I was suggesting to abstract this out fundamentally so we can get things like this done. I'm sorry if this became an Xy problem.]

Ok - I'm now thoroughly get confused. Toga has no representation of OptionContainer on iOS that isn't a "bottom of screen" tab bar. UINavigationController et al are iOS specific APIs.

What are we even discussing here? Is it Liquid Glass rendering issues? New possible interpretations of OptionContainer? iOS internal representations of Controllers?

We've raised this issue with your communication style in the past, but it's becoming a serious problem again. Focus matters.

If we are on a thread that is titled "OptionContainers In Toga in regards to usage in small sections vs top level structure" - that conversation needs to be about OptionContainers In Toga, and different ways of rendering them. And nothing else. So far, other than the initial post where you showed a bunch of alternative screenshots of things that might be OptionContainers, the only thing that isn't being discussed is alternate representations of OptionContainer.

If there's a detail that needs to be discussed about one specific platform - then maybe we need a different thread to discuss that issue. If there's overlap between two issues, then cross link as appropriate, or start a thread to discuss the overlap.

Your reply came 5 minutes after I posted my response. It is impossible that you've given a considered response to what I wrote in less than 5 minutes. It would have taken 2 minutes to type what you wrote, let alone any time to get the notification, consider it, draft a response, fix typos...

Slow down. Take your time to consider things, say less, and be clear in what you're communicating. Make the choice of where you post an active part of the posting process. Actively choose the channel in which you're making a comment, and focus on being clear in exactly what you're trying to say, and why you're saying it.

[johnzhou721]

@freakboy3742

First off, I acknowledge that my communication style was problematic. I will be taking action to start a new thread later with the root cause.

@freakboy3742
FWIW -- I apologize that I was not being clear with the point. But with regular OptionContainers, this is not a concern; only the tab bar representation of it is, so I was suggesting to abstract this out fundamentally so we can get things like this done. I'm sorry if this became an Xy problem.]

Ok - I'm now thoroughly get confused. Toga has no representation of OptionContainer on iOS that isn't a "bottom of screen" tab bar. UINavigationController et al are iOS specific APIs.

For the actual confusion here: By regular I meant like a segmented control and then a view below, like the one in the Mail app, or about any option container used as small sections instead of top-level structure.

What are we even discussing here? Is it Liquid Glass rendering issues? New possible interpretations of OptionContainer? iOS internal representations of Controllers?

I will be moving iOS internal controller / view hierarchy to a new thread (to be posted a little later), pointing to this as a possible solution to manage things easier. For now we can leave this thread on hold until we decide is needed, or treat this as a cosmetic issue to be solved when all the other bigger fishes are done if we decide there's a way to make iOS native hierarchy work without an abstraction like this.