Architecture

Xilem architecture.

A contributor-level map of the Runebender Xilem source architecture. This page is intentionally structural: it explains where responsibilities live without turning internal modules into a stable API contract.

Status	Alpha architecture map
Audience	Contributors, maintainers, documentation agents
Source	Current local Runebender Xilem source tree
Stability	Architecture names may move while the app is alpha

Application flow

The app starts in src/main.rs, calls into runebender::run, builds Xilem state, then switches between welcome, glyph grid, and editor surfaces depending on loaded font state.

Runtime outline
Entry	`src/main.rs` creates the Xilem event loop.
Run	`src/lib.rs` initializes logging, config, initial state, command-line loading, and the Xilem app.
State	`AppState` drives the reactive UI and owns loaded workspace state, selection, active editor session, grid state, clipboard, and file-watch flags.
Views	When a font is loaded, the app presents glyph grid and editor tabs. Without a loaded font, it shows the welcome view.
Reload	The tabbed view is wrapped with a file watcher that can reload workspace data after external UFO changes.

State model

src/data/mod.rs describes AppState as the central application state that drives the Xilem reactive UI.

workspace holds the loaded UFO workspace when opening a direct source.
designspace is reserved for designspace project state.
editor_session and welcome_session hold active editing contexts.
active_tab, selected glyph data, grid scroll state, and category filters drive navigation.
clipboard, save_in_progress, and glyph_images_dir support editing, file watching, and image workflows.

Editing layers

Interaction model
`src/editing/`	Local interaction modules for background images, hit testing, mouse behavior, tracing, QuiverAI, viewport helpers, and edit sessions.
`runebender-core`	Shared editing types for selection, undo, and edit type concepts are re-exported through `crate::editing`.
`src/tools/`	Tool implementations handle pointer and paint behavior for Select, Pen, HyperPen, Knife, Measure, Shapes, Text, and Preview.
`ToolBox`	Wraps the active tool and delegates mouse, paint, and edit-type behavior.
`EditSession`	Holds the active editor interaction context used by tools and canvas event handling.

Data and geometry

Source data
`src/data/`	Application-facing editor data, file IO, grid behavior, and kerning.
`src/model/`	Workspace, designspace, and glyph rendering concepts.
`src/path/`	Cubic, hyperbezier, quadratic, point, point-list, segment, and quadrant path data.
`src/shaping/`	Arabic shaping and Unicode data support.
`src/sort/`	Buffer, cursor, and data modules for text or glyph ordering behavior.

Use this page

Use Source map for file-level orientation.
Use this page for subsystem boundaries and responsibility flow.
Use Verification before turning source behavior into public docs.
Use the source repository for exact behavior before making implementation claims.
Update this page when source modules move or when the public architecture becomes stable enough for deeper docs.