Add an OptionScaffold

[freakboy3742]

What is the problem or limitation you are having?

After the introduction of Scaffolds in #4298, we'll be able to introduce an OptionScaffold, providing a way to display app-level tab content.

Describe the solution you'd like

The API for OptionScaffold and OptionContainer should be largely similar.

On desktop, the underlying implementation will also be largely similar (i.e., a root level widget that provides "top of window" tabs).

On mobile, the underlying implementation will reflect the historical "Primary" (pre-#4297) rendering of OptionContainer. It should be able to re-use much of the implementation and tests as well.

Describe alternatives you've considered

Additional context

See discussions on #4271 for background.

[johnzhou721]

On desktop, the underlying implementation will also be largely similar (i.e., a root level widget that provides "top of window" tabs).

I'd like to say that on all three platforms, there'll be slightly more native ways to represent top-level tabs. So it may not be word or word similar with the previous widget's we've got.

[freakboy3742]

Sure - "tabs in the titlebar" type representations are possible on desktop; my point was that v1 of an implementation doesn't have to explore those options unless it's convenient or trivial to do so.

[johnzhou721]

Sure - "tabs in the titlebar" type representations are possible on desktop; my point was that v1 of an implementation doesn't have to explore those options unless it's convenient or trivial to do so.

Some food for thought: "Tabs in titlebar" can also appear on other views that are pushed as depth navigation, not just the root one. That can certainly be v2. Tabs in titlebar are also possible on mobile as well as a second depth of tabs (but to be honest, not that much benefit to just using OptionContainer, you just get more native effects on iOS and maybe some saved real estate if you don't have a title.)

I'd have to agree with setting hard boundaries for what will be v1. I'm planning to get a common ground discussed on exactly what should be impleented for #4298 to #4305 as v1, down to the implemenation details, after sufficient discussion. I'm drafting my message in this regard for #4298 now.

[johnzhou721]

Sorry for my vague comment regarding non-toplevel tabs-in-titlebar above. The point I was trying to make was that while tabs in title bars can represent "top-level" tabs as in the macOS Clock app, they could also be used to represent tabs in other contexts, such as a "detail" view in the DetailContainer:

So... how should we accommodate for this? Should we even be having a conversation about this now?

Tabs in title bar is valuable to save some screen real estate sometimes if we do the tabs-in-title-bar, especially on iOS and macOS. On Android, there's also a more native representation than OptionContainer there for tabs that are for an entire page (namely, "primary tabs").

My fear is that some API decisions we make right now may preclude us from adding tabs-in-titlebar functionality in the future... non-toplevel tabs-in-titlebar can show up at:

• The middle/right panes of a SidebarScaffold or DetailScaffold, for any pane
  • Note, that I previously wanted to represent this with Scaffold nesting. However, it's more lightweight, and not a top-level structure like the usual scaffolds.
• Each "selection" of an OptionScaffold (see: iOS 18 phone app, where in the Call tab on the bottom, there's also All/Missed tabs on the top.)
• The "pushed" content of a DetailContainer
  ... where "(icons, tab text, and content) list" will replace the "content widget" of each of those situations.

That said, it simply may be appropriate to accept a list of icons, tab text, content instead of a single widget whenever we want to support tabs on this contexts, on a case-by-case basis. It's not a major issue, but it does save some real estate on Linux, macOS, and iOS, so we don't have to deal with it now.

Thoughts? Should we just accept that if this ever wants to be implemented in the future, we could just do it on a case-by-case basis like what we said above, and live with current API design for now? I think so, as to not sidetrack things too much.

[freakboy3742]

Sorry for my vague comment regarding non-toplevel tabs-in-titlebar above. The point I was trying to make was that while tabs in title bars can represent "top-level" tabs as in the macOS Clock app, they could also be used to represent tabs in other contexts, such as a "detail" view in the DetailContainer:

How is that not an OptionContainer?

So... how should we accommodate for this? Should we even be having a conversation about this now?

I am still unclear what it is we're having a conversation about.

However - broadly speaking: we do not need to solve every problem immediately. We need an API that works for a clear set of use cases, with the ability to add other options or interpretations in future. In the examples you've provided, it's not clear to me why that isn't either (a) an OptionContainer, or (b) some other interpretation of an OptionContainer-like structure that fits inside the existing content structure.

[johnzhou721]

However - broadly speaking: we do not need to solve every problem immediately. We need an API that works for a clear set of use cases, with the ability to add other options or interpretations in future. In the examples you've provided, it's not clear to me why that isn't either (a) an OptionContainer, or (b) some other interpretation of an OptionContainer-like structure that fits inside the existing content structure.

It's supposed to be (b). It renders a bit differently and in iOS and macOS, can render into a title bar and needs to be coded a bit differently.

But given that you agree it fits inside the existing content structure, this was what I'm trying to get concensus on in this conversation. Technically, we're open to adding this possibility if deemed necessary.

EDIT: Looks like one could use Container.set_content to check if it's an OptionContainer to automatically move things to the titlebar and/or enable primary style on Android. Some bookkeeping needs to be done, but overall this can still be done with OptionContainer