Overview

FlashBang is designed around a few ideas that show up directly in code:

Immediate mode

You do not build a retained widget tree in application code. Each frame you pass a ^ImmediateContext, configs (FooConfig), and you read back FooState where applicable. Persistent input state (e.g. “was the button active last frame?”) is your responsibility; the library tells you what happened this frame.

The global immediate context is updated with flashbang.set_immediate_context (and optional set_*_backend calls at startup). See Immediate mode for the full loop.

Renderer-neutral output

Widgets call into rendering to enqueue things like filled rects, strokes, and text runs. Your adapter turns the resulting DrawList into actual rendering. FlashBang’s core does not call SDL, OpenGL, or similar directly.

Theming

Visuals come from a style.Theme value: colors, radii, optional procedure hooks (geometry, resolve, indicators, window chrome, etc.). Widgets typically call style.resolve_surface (or your theme’s resolve proc) to get a ResolvedSurface, then flashbang.emit_surface (or themed separator helpers) to emit draw ops. Details are in Theming.

Layout

You can place widgets with explicit x, y, w, h in configs. Optionally, a LayoutBackend (e.g. Clay) can publish rectangles per widget id for the frame; widgets call internal helpers to override local rects from that cache. Measurement helpers exist for integrating external layout engines—see flashbang.run_layout_backend and the layout types re-exported from flashbang.odin.

Where the API is defined

The package flashbang entry point is src/flashbang.odin in the library repo. It mostly re-exports widgets and style symbols under stable names (Button, Label, Theme, …). When you read “the API,” start there, then open the underlying src/widgets/*.odin or src/style/*.odin file for the full procedure bodies and comments.