GlassPinnedBarChrome class

Hands a route's bar chrome to the enclosing GlassNavigationShell, and builds whatever the bar should render in the meantime.

This is the registration GlassAppBar.pinned performs internally, exposed for bars this package does not build — a Material AppBar carrying its own backdrop, a collapsing large-title sliver, or anything else an existing design system already owns. Declare the items as data once and drop the resolved slots into your bar:

GlassPinnedBarChrome(
  actions: [
    GlassBarItem.icon(icon: const Icon(CupertinoIcons.add), onTap: _create),
  ],
  builder: (context, chrome) => AppBar(
    automaticallyImplyLeading: false,
    leading: chrome.leading,
    actions: chrome.actions,
    title: const Text('Repository'),
  ),
)

The slots swap themselves at the right moment. Until the shell has both accepted the registration and had a frame to render its copy, they hold the real glass back button and actions capsule — the same widgets the shell will draw. After, they hold unpainted placeholders that lay out the real content, so the bar keeps the layout it had and the title never shifts. The hand-over is deliberately a frame late: at the swap both copies are static and identical, so they never overlap and never both disappear.

The hand-over runs in reverse too. While a dialog or a modal sheet is presented over the route the shell has nowhere valid to draw — it sits above the Navigator the presentation was pushed into — so the slots take the real buttons back and the presentation covers them along with the rest of the page. The capsule a GlassBarItem.sheet morphs out of is the one exception: the morph has emptied it, so it stays hoisted and its slot keeps the placeholder until the droplet is poured back.

Where there is no shell — or the device cannot render the effect — the slots simply keep the real buttons, so a bar written this way works either way with no fallback of its own.

On iPhone Duo, where the shell has resolved a vertical bar strip (GlassVerticalBar), the slots keep only the items that stay horizontal, and everything else — the back button first — stacks in the strip. The shell draws the strip while it has the chrome; while it has handed the chrome back, this widget draws it, above its own route and below whatever is presented over it. Either way the strip is never the bar's to draw, which GlassPinnedBarChromeData.inStrip tells a builder drawing its own chrome.

A bar inside a presented route — a GlassModalSheet's — never registers: the presentation comes up over the stack the shell pins across, so it is the bar's container, and the bar draws its own chrome there. In the strip layout it follows the sheet's own strip.