App-level Concepts: Windows, Dialogs, TopAppBar, etc

[rcoreilly]

Dialog vs. Window

Decision 1: Logical flow

• Dialog = Context + Modal:

  • Necessary flow logic: must either proceed or cancel (could be multi-step)

• Window = no Context + non-Modal

  • Persistent, no mandatory flow

Decision 2: Size and capacity

WindowTypes enum:

PopupWindow
FullWindow
NewWindow // on mobile, same as Fullwindow

Dialog

• PopupWindow: Small, minimal content: use gi.NewDialog method.
• FullWindow: large, could have other dialogs: use gi.NewFullDialog method.

Window

Always at least FullWindow

• NewWindow: separate content, default for NewWindow() Stage method
• FullWindow: option for e.g., web browser pages -- lots of similar content, don't want separate windows.

Header, Footer etc "Control Zones" (CZ)

• Header is typically at least (but not exclusively) TopAppBar

• TopAppBar has specific support in Scene -- var DefaultTopAppBar adds global default "main menu" functionality, Preferences, Inspector etc -- can set this to app-specific one to get additional / different defaults for every app bar (should mostly put things directly into overflow menu). giv uses TopAppBar when present.

• Footer, Left can have app-specific nav-bar functionality, etc.

  • "OK" and "Cancel" buttons on Dialogs are a good high-frequency use of Footer.

• Each has a stack of functions -- functions can be inherited, shared, added to.

• Windows don't automatically inherit CZs: specify their own (could all be same function)

• Dialogs sometimes inherit CZ from context, sometimes don't. Sometimes add additional funcs to top app bar.

Body, Scene, Stage

• Need for inheritance + functional basis of CZ requires that "main content" be specified in a separate element from the CZ elements, which are dynamic, compositional etc, whereas the main content is "bespoke" -- particular to a specific window etc.

• Body is this main content container -- always make the specific content in a Body, which then gets attached to the Scene.

• Scene remains the full encapsulated "rendering unit" -- a chunk of widgets that are all arranged (Layout) and rendered together onto a specific set of dedicated Pixels.

  • Menu, Tooltip, Snackbar start with NewEmptyScene and bypass the Body and CZ logic. This is always an option for anyone who also wants to skip this stuff (e.g., for tests)

• Stage manages the presentation of the Scene, in relation to other Scenes, RenderWin windows, etc. Popup vs. FullWindow, etc.

• Body: duplicates all the functionality of Scene so that you can operate directly on it without needing to juggle two variables, for the Scene and Body.

giv Dialogs

• StructView, SliceView (TableView) etc are large elements, have FullWindow Dialogs
• Dialogs default inherit CZ from context.
• MapView, SliceView+ use TopAppBar if present, add their specific functions there (Add, Sort)
• Key question: how to change this default? Needs to be specific to particular chain of context -- one idea is to have additional params on CZs that specify giv inheritance policies.

Inheritance

• Inherit bool for each CZ. If true, FullDialogs inherit CZ from context. By default, only Header is true.

[rcoreilly]

Using "Bars" for the generic term for the control zones on different sides of the window -- TopAppBar, NavBar, ToolBar etc -- covers most of the connotation. Type will be Sides.

[rcoreilly]

Three control flow scenarios according to Kai

1. OK = acknowledge -- no other alternative. No back arrow, no Cancel. This is supported easily with AddOkOnly method. The main question here is whether to use a Dialog vs. Snackbar in this case (e.g., for Error messages, which is the typical use-case).

2. OK + Cancel = OK does something. In this case, the back button should be disabled, or if present, it should spawn a modal Ok / Cancel dialog. In general much better to not to have the back arrow in the first place in this case.

   • 2a. Close X (in upper left) = in many cases there is another effective "OK" action for going forward with the action (e.g., in composing an email, you can either hit the Send button or hit X to cancel). So this is a more concrete labeling of Ok + Cancel.

3. Back Arrow (in upper left) = in context of no confirmation or other "forward" action; changes are applied immediately, and back arrow just closes the dialog.

The only challenge is figuring out when to use 2 vs. 3.

Relevant factors:

• Back arrow requires some method of Undo, in lieu of Cancel, or else only involves very simple, non-destructive changes that can easily be updated when you realize you've done the wrong thing.

• Ok / Cancel seems more appropriate for creation / deletion events (e.g., making a new thing of some sort, opening a new file, etc) vs. Back arrow for changing settings (twiddling preferences, etc)

Value self-triggered OpenDialog vs. FuncButton use of Dialogs

• Value self-Dialog = back arrow always -- no action (except for FileView?)

• FuncButton is always OK + Cancel because you either call the function or not.

• Popup (FullWindow = false) dialogs always require OK + Cancel