gpui-ai

Progress

Status badge

One status pill for every lifecycle, swapping states in a fixed slot.

Status badge — gpui-ai

Starts when it scrolls into view

Pop out

NORD FROST · DARK · RADIUS 6/10 · BASE 16PX · SHADOW

Running the real component, compiled to WebAssembly. The frame is 84 px tall, which is what this story measures at the demo width in the default type size — a narrower column or a theme that changes that size will wrap it differently.
Source
status.rs
Story
status
Demo height
84 px
Events
None

Code

Cut from the gallery story this page runs, so it stays true.

crates/gallery/src/gallery.rsOpen in the galleryImplementation
v_flex()
    .gap(tokens.spacing.md)
    .child(
        h_flex()
            .flex_wrap()
            .gap(tokens.spacing.sm)
            .child(StatusBadge::new("status-neutral", "Queued"))
            .child(
                StatusBadge::new("status-info", "Indexing")
                    .tone(StatusTone::Info)
                    .active(true),
            )
            .child(
                StatusBadge::new("status-success", "Deployed")
                    .tone(StatusTone::Success),
            )
            .child(
                StatusBadge::new("status-warning", "Needs review")
                    .tone(StatusTone::Warning),
            )
            .child(
                StatusBadge::new("status-danger", "Rolled back")
                    .tone(StatusTone::Danger),
            ),
    )
    .child(StatusBadge::for_progress("status-driven", &driven))

Events and ownership

Who owns the state
StatusBadge renders state supplied by the application; it does not own durable work.
What it emits
This presentation surface adds no component-specific interaction event.
What it means
One status pill for every lifecycle, swapping states in a fixed slot.
Overflow and motion
Wide content retains context in a bounded surface; reduced motion preserves a useful state.

What the demo does and does not show

The demo above is the same Rust as the native component, compiled to WebAssembly and drawn on a WebGPU canvas — not a mock-up, a recording, or a re-implementation. What it paints is what the component paints: layout, colour from the live theme, and motion.

The live browser specimen requires WebGPU; the native component remains the authoritative runtime.

A canvas cannot stand in for the platform, so treat everything that goes through the operating system as unproven here: keyboard handling and shortcuts, screen reader semantics, text input and IME, the clipboard, file drops, and the frame rate you would get on your own GPU. Judge those in a native build. If your browser has no WebGPU, the frame says so rather than showing an empty box.