ansiq-widgets

ansiq-widgets contains:

• low-level primitives such as Block, Paragraph, List, Table, Tabs
• higher-level compositions such as shell-oriented UI building blocks

Its job is not to replace the runtime. Its job is to:

• provide builder-style widget construction on top of Element
• package common terminal UI patterns as reusable widgets
• expose shell/session-oriented compositions without leaking app-specific logic into runtime layers

Where to learn how to use them

Use the dedicated Widgets section when you want:

• usage-oriented examples
• which widget to pick for a given UI problem
• common combinations such as Shell + SessionTranscript + ComposerBar

Treat rustdoc as the exact interface reference.

Low-level primitives

The most common low-level widgets are:

• structure: Box, Block, Pane, Shell
• text: Text, Paragraph, RichText, StreamingText
• input and collections: Input, List, Tabs, Table
• scrolling: ScrollView, Scrollbar
• visualization: Gauge, LineGauge, Sparkline, BarChart, Chart, Canvas

These widgets exist to:

• package common props into stable builder APIs
• plug stateful widgets into continuity and routing contracts
• let both builder style and view! compile to the same retained Element tree

Higher-level compositions

ansiq-widgets also includes more obviously shell-oriented compositions:

• StatusBar
• BottomPane
• ComposerBar
• SessionHeader
• SessionTranscript
• TranscriptView

These are a good fit for:

• session shells
• streaming interfaces
• explorer and dashboard-style terminal apps

They should help structure UI, not absorb business logic or networking.

Builder style and view!

Ansiq widgets can usually be written either as builders:

let list = List::new(items).highlight_symbol("> ");

or declaratively:

view! {
    <List items={items} highlight_symbol={"> "} />
}

Both forms end up producing the same Element model. The choice is mostly about how you want to organize view code.

What belongs in this crate

Good candidates for ansiq-widgets:

• reusable widget builders
• reusable shell or session compositions
• widgets with clear continuity, routing, or rendering contracts

Poor candidates:

• app-specific pages
• one-off compositions used by only a single example
• networking, system sampling, or OpenAPI loading logic

Those belong in examples/ or in separate application crates.