Files
essim/doc
François 792e4745d3 Merge search and net screens into explore; drop both commands.
`explore` was already a superset of `search` (4 columns: module → type
→ filtered children → detail, with parts/signals/connections — vs
search's 2 columns of parts/signals only). It now also subsumes the
former `net` screen: when a signal entry is selected, the detail pane
shows the local pins followed by a `Net members (across connections)`
section listing every `(module, signal, type)` reachable through the
BFS over `Connection::pin_map`, with the count + dominant type and an
INCONSISTENT flag in the signal-detail header.

Removed:
- `src/tui/screen_search.cpp`, `src/tui/screen_net.cpp`.
- `commands["search"]`, `commands["net"]` (including its textual
  inline form). The `find_net` / `Net` API stays for explore's BFS
  panel and the analyze screen's net-mix check.
- `[s]` and `[n]` letter shortcuts on the dashboard.
- `net_*` and `search_*` state members + builders + constructor
  inits.

screen_idx renumbering (the slots vacated by search + net are
removed, not left dead):
  0 = console  (unchanged)
  1 = connect
  2 = set-connector-type
  3 = explore  (unchanged number, but now subsumes search + net)
  4 = dashboard (boot)
  5 = analyze

Palette signal items now jump to `explore` prefilled on the signals
tab with the child filter seeded to the exact signal name; the BFS
section in the detail pane is what shows the cross-module net.

Net-member rows in the detail pane are deliberately read-only for
now (Enter is a no-op): the signal-type popup is scoped to the
currently selected module, so opening it on a peer-module member
would mis-fire. Cross-module Enter navigation can come later if
needed.

DESIGN.md and user docs updated accordingly.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-14 21:49:26 +02:00
..
2025-04-21 18:19:37 +02:00

essim documentation

Auto-generated API reference and high-level design notes for the essim system digital twin.

Layout

  • user/user-facing docs (hand-written intro/tutorial
  • api/developer-facing API reference (Doxygen XML → custom Markdown emitter). Browse classes and files directly in gitea's Markdown renderer. Top page: api/index.md.
  • ../DESIGN.md — implementation notes: domain conventions, TUI flow, gotchas. Hand-maintained.
  • classes.puml — PlantUML class diagram for the domain model. Render with plantuml classes.puml for a PNG/SVG.
  • Doxyfile.in / gen_api_md.py — the toolchain (templated Doxygen config + custom XML→Markdown emitter).

Regenerating the API reference

The Markdown tree under doc/api/ is committed so it's readable directly on gitea. After substantive code changes, regenerate it:

# 1. Tooling (once): Doxygen, plus a Python 3 interpreter (already on Arch).
pacman -S doxygen

# 2. Configure once (or after editing doc/Doxyfile.in):
cmake -S . -B build

# 3. Regenerate:
cmake --build build --target doc

# 4. Review and commit the updated doc/api/ tree:
git add doc/api/
git status doc/api/

Pipeline:

src/**/*.{hpp,cpp}  ──┐
README.md            ─┼─► doxygen ─► build/doc/xml/  ─► gen_api_md.py ─► doc/api/
DESIGN.md            ─┘            (Doxyfile.in)

(built essim) ────────► essim --commands-md ──────────────────────────► doc/user/commands.md

doc/user/index.md and doc/user/scripting.md are hand-written; only doc/user/commands.md is regenerated. The doc target depends on the essim binary so a stale build is rebuilt before the dump is taken.

If either Doxygen or Python 3 is missing at CMake-configure time the doc target is silently disabled (the regular build still works) and a status line is emitted in the CMake log telling you which one to install.

Why a custom emitter rather than doxybook2 / moxygen

  • doxybook2 is not packaged in Arch / AUR and gets stale upstream.
  • moxygen drags Node into a pure-C++ project.
  • The emitter is one Python file (gen_api_md.py, ~330 lines) with zero external dependencies — easy to read, easy to tweak, robust to Doxygen version changes (the XML schema is stable).

Tailor the output by editing gen_api_md.py directly: add columns to the class table, change the source-link format, group sections differently, etc.

Comment style

The codebase uses standard Doxygen markers:

  • /// for single-line briefs.
  • /** … */ for multi-line blocks.
  • @param, @return, @brief (or @short) tags inside blocks.
  • @throws for exceptions a function may raise.

JAVADOC_AUTOBRIEF = YES is set so the first sentence of a multi-line comment counts as the brief description without needing an explicit @brief tag.