astepaniuk/cad-research

1. Overall shape

- This is a C++/CMake desktop CAD prototype centered on 2D floor-plan editing.

- The code is split into three main product layers: core infrastructure (corecad), domain logic (domain/plan), and GUI/editor (gui).

- Tests are organized by the same boundaries, which makes the intended architecture fairly explicit.

2. Build and dependency boundaries

- The project is built with CMake and uses vcpkg for package management.

- Two bundled third-party dependencies matter architecturally:

- ImGui for the immediate-mode UI.

- freecad-planegcs for geometric/constraint solving in the sketcher-like parts of the model.

- The repository also includes a standalone GitHub Actions workflow for multi-platform CMake builds.

3. CoreCAD: shared modeling infrastructure

- src/corecad is the generic, reusable foundation beneath the plan domain.

- It contains infrastructure for:

- model objects and properties

- registries / stable indexing

- trackable registries

- history/undo-redo transactions

- generic constraints and calculators

- This layer looks intentionally domain-agnostic: it provides the mechanics for state management, referencing, and calculations without knowing about walls or floors.

4. Domain model: floor-plan concepts

- src/domain/plan/model defines the actual business objects:

- floor

- wall

- typed parameters such as distance, point_locator, and wall_border_point_locator

- The domain model is split into subfolders for shape and parameter, which suggests the design separates geometric entities from their editable/derived inputs.

5. Domain generation and resolution

- src/domain/plan/generator/default_floor_generator creates initial floor content.

- src/domain/plan/resolver/point_resolver and the parameter locators suggest a two-step approach:

- resolve abstract/editable parameters into concrete geometric points

- then use those points to drive shape updates

- This is the bridge between user intent and actual geometry.

6. Domain calculation

- src/domain/plan/calculator/wall_calculator is the central computation unit for wall geometry.

- The tests show it calculates wall borders for:

- a single wall

- added walls

- two walls

- multiple joined walls

- That implies the calculation layer is responsible for updating wall extents and intersections when topology changes, not just storing coordinates.

7. GUI application boundary

- src/gui/main.cpp is the application entry point.

- main_window is the top-level UI shell, with a workspace and main_menu around the active editor/document area.

- The GUI is organized around a central document/view/editor structure rather than a generic widget tree.

8. Document and view layer

- src/gui/doc/document.h appears to hold the editable document state for the UI.

- wall_snaps sits in the document layer, hinting that snapping aids are part of document state or derived document services.

- src/gui/view contains rendering-oriented views:

- floor_view

- walls_view

- constraints_view

- parameters_view

- coord_translator indicates a clear separation between screen coordinates and model coordinates.

9. Editor interaction pipeline

- src/gui/editor is the interaction engine for manipulating the model.

- The structure is stateful:

- operation classes represent active tools or modes such as add-wall, idle, and move-wall-handle.

- handler classes encapsulate specialized behaviors like wall joins and T-joins.

- mouse centralizes pointer state.

- This suggests a tool-driven editor architecture where input events are interpreted by the active operation, which then mutates the document/model.

10. Snapping and editing assistance

- src/gui/editor/snap contains snap construction and processing:

- vh_snap_builder

- snap_processor

- i_snap_builder

- These components likely compute candidate alignments or target points before the editor commits a move or placement.

- Snapping sits between raw mouse input and model mutation, acting as an editor-side geometric assistance layer.

11. Calculation pipeline in the GUI

- src/gui/editor/calc_pipeline suggests the GUI has its own orchestration layer around calculations, probably to sequence resolver/calculator passes while editing.

- This is important architecturally because it means geometry updates are not direct UI writes; they likely flow through a staged pipeline that keeps the view/editor responsive and model-consistent.

12. Data flow through the system

- The main flow is:

- user input in the GUI

- active editor operation/handler interprets the input

- snap processing and point resolution refine the edit intent

- domain model changes are applied

- calculators recompute wall/floor geometry and constraints

- views render the updated document

- Undo/redo and transaction history in corecad/model/history wrap this flow so edits are reversible.

13. Testing boundaries mirror the architecture

- corecad_tests focus on history/transaction behavior.

- domain_tests focus on wall calculation correctness.

- common_test_util provides assertion helpers shared across test groups.

- This separation reinforces that the repo’s primary design concerns are model consistency and geometric recalculation, not just UI behavior.

14. Likely diagram boundaries

- A clean architecture diagram should show:

- GUI/editor at the top

- Domain plan model + calculators in the middle

- CoreCAD infrastructure + history/constraints underneath as reusable services

- Third-party geometry/solver libraries as external dependencies feeding the calculation layer

- The most important cross-boundary interactions are editor-to-domain updates, domain-to-calculator recomputation, and history wrapping of state changes.