Files
OneCAD-Draft/help
Felix RiestraandClaude Sonnet 5 7cddf31bcb Add named parameters, UI scale setting, OPTIONS/OP dispatch, and help manual
Named parameters (docs/named_parameters_design.md, stages 3-4):
- ParameterTable (src/scene/named_parameters.rs): a document-wide table of
  named formulas, each resolved through a shared expression evaluator with
  cross-parameter references, cycle detection, and division-by-zero/parse
  error reporting. SketchConstraint::driving_param becomes DrivingValue
  (Literal | Named) instead of a bare f64, resolved at solve time by
  sketch_solve::build_constraint via Scene::named_parameters.
- Persistence (src/scene/named_parameters_persist.rs): same lazy XRecord
  model sketch_persist.rs already established, synced around open/save.
  Bumps the sketch-constraint XRecord's own format version (1 -> 2) since
  DrivingValue's shape doesn't line up with a version-1 blob's bytes.
- PARAMETERS command and its editor (src/ui/window/named_parameters.rs):
  add/remove/edit rows, live validation, duplicate-name detection: Apply
  defines the table and re-solves every constraint scope with a
  named-parameter-driven constraint (command_driver.rs). Distance/Angle
  constraint prompts (modules/draw/constrain/value.rs) now accept either a
  literal or an existing parameter's name, mirroring how the constraint's
  own value prompt already worked.
- Undo scope-down carried over from this project's own established pattern
  (constraint-system stage 9): the geometry an Apply moves is one undo
  step, but the parameter table edit itself has no undo entry yet — a
  documented follow-up, not a silent gap.

UI scale setting (src/app/settings.rs, app/mod.rs, ui/window/options.rs):
  a whole-interface scale percentage (50-200%), wired directly into iced's
  own per-window scale_factor hook rather than per-panel font-size
  plumbing, so it applies immediately to every panel, dialog, and the
  ribbon at once. Persisted alongside the existing lineweight-display-scale
  setting.

OPTIONS/OP command dispatch (app/commands/view.rs, app/commands/mod.rs):
  OPTIONS was registered for autocomplete but had no dispatch arm — the
  Start-tab welcome screen's own button was the only way to reach it.
  Found live-testing the UI-scale setting, unrelated to that feature
  itself. "OP" is AutoCAD's own short alias.

help/: a new self-contained static user-help manual (manual.md as the
authored source, tools/build_help.py splits it into the committed static
HTML pages plus search index) — not yet wired into the application.

64 new/updated tests across the named-parameters and constraint-prompt
changes.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-09 13:50:08 +02:00
..

OpenCAD Studio Help

This directory is a self-contained, static user-help system. It is intentionally not wired into the application yet.

Authoring model

  • manual.md is the single source of truth for user-facing prose.
  • tools/build_help.py splits the level-two chapters into static HTML pages.
  • assets/css/ and assets/js/ provide the shared responsive presentation, navigation, dark mode, print styling, and local search.
  • context-map.json reserves stable help targets for future command/dialog integration without changing application source now.
  • assets/images/ is for screenshots and workflow illustrations referenced by manual.md.

Generated HTML and search-index.js are committed so the manual works directly from disk without a web server. Do not edit generated pages by hand.

Build and validate

Requirements: Python 3 and Pandoc.

python3 help/tools/build_help.py
python3 help/tools/build_help.py --check
python3 help/tools/check_help.py

Open help/index.html in a browser to review the generated manual. When future application work is safe, package the complete help/ directory and connect the Help menu or contextual controls to the URLs in context-map.json.

Content rules

  1. Keep level-two headings unique; each one is a chapter boundary.
  2. Keep level-three headings stable because their generated IDs are public help targets.
  3. Describe observable behavior, not implementation details.
  4. Use task-first procedures and state prerequisites before numbered steps.
  5. Mark safety, compatibility, data-loss, and known limitations explicitly.
  6. Regenerate and run both checks before committing documentation changes.