Describes a time-varying overlay an inline control exposes to its hosting InlineDialog. The
dialog adds it to the grid once (through the normal CliGrid.AddOverlay system) and never
rebuilds the grid when the content changes — the overlay's renderer reads the live
Ticker on every render, so animation rides on the cached grid. Placement is given
relative to a dialog Area, matching how widgets are placed, so controls never depend
on absolute grid coordinates. The overlay is a horizontal strip on the area's row, running from
ColumnOffset to the end of the area.
Base class for dialog-hostable inline controls. Controls render themselves as grids, handle keys
through InlineKeyResult, and can expose dialog metadata such as hints, labels, widgets,
overlays, and completion state.
Describes one top-level widget/area an inline control exposes to its hosting InlineDialog.
A control may expose a single widget (the common case, preserving the legacy single-content
behavior) or several, each placed into a fixed InlineDialogArea.
A reusable interactive building block used inside composite inline controls. A widget renders
itself into its own subgrid and handles keys, but — unlike InlineControlBase — it
is not necessarily dialog-hostable on its own. It is a part, not a whole.
A time-driven source of overlay content for semi-interactive dialogs. A ticker owns a frame/content
that changes at a fixed Interval while it is IsActive. The hosting modal
loop advances every active ticker once per iteration via Advance(DateTime); when a ticker reports
its visible output changed, the loop re-renders. Tickers carry no rendering or layout logic — they
only expose CurrentContent, which the dialog's overlay renderer reads.
The outcome of an inline control/widget handling a key. Beyond "handled / not handled" it can
request a dialog result, so a focused widget (e.g. a button) can complete the hosting dialog
directly instead of relying on the dialog's Enter/Escape fallback.
Filesystem navigation policy used by InlineFolderSelect. The control is agnostic to
the underlying filesystem and platform; all platform rules (drive lists, root behavior,
parent resolution) and all error handling live behind this abstraction.
Implemented by a dialog that needs to know the bounds of its modal session — when the semi-interactive
modal loop begins and ends hosting it. The shell calls OnModalOpened(CancellationToken) once before the
first render, supplying a token cancelled when the modal closes for any reason, and
OnModalClosed() exactly once on exit (key result, timeout, external cancellation, or
exception). Used to give controls a cancellation token for background work and a safe teardown point.
Implemented by a dialog that has time-driven content (periodic overlays). The semi-interactive modal
loop calls AdvanceAnimations(DateTime) once per iteration on its own render thread and re-renders
only when it returns true. The shell owns the loop and timing; the dialog owns which tickers
exist and whether any of them changed.