Extract file menu binding and Win32 splash helper

This commit is contained in:
2026-06-16 11:10:31 +02:00
parent 8afeb087b8
commit d135835787
8 changed files with 369 additions and 232 deletions

View File

@@ -80,10 +80,10 @@ What is still carrying too much live ownership:
Current hotspot files:
- `src/canvas.cpp`: 2645 lines
- `src/app_layout.cpp`: 1498 lines
- `src/app_layout.cpp`: 1360 lines
- `src/canvas_modes.cpp`: 1798 lines
- `src/node.cpp`: 1551 lines
- `src/main.cpp`: 1374 lines
- `src/main.cpp`: 1181 lines
- `src/node_panel_brush.cpp`: 1197 lines
- `src/node_stroke_preview.cpp`: 933 lines
- `src/node_canvas.cpp`: 888 lines
@@ -127,7 +127,9 @@ Current architecture mismatches that must be treated as real blockers:
rather than thin composition/binding surfaces, even though tools-menu binding
plus nested panels/options submenu wiring now live in
`src/app_layout_tools_menu.cpp` and `App::init_menu_tools()` is now a thin
call-through.
call-through, while file-menu binding plus the export submenu wiring now also
live in `src/app_layout_file_menu.cpp` and `App::init_menu_file()` is now a
thin call-through.
- `App`, `Canvas`, `Node`, retained workers, and platform entrypoints still use
global singleton reach, raw observer pointers, retained static worker
ownership in several app families, and ad hoc mutex/condition-variable
@@ -149,7 +151,10 @@ Current architecture mismatches that must be treated as real blockers:
local worker-state helper instead of a bare static accessor, the
prepared-file worker and the canvas async import/export/save/open worker now
live under `AppRuntime` instead of retained static app-events/canvas
workers, `App::rec_loop()` now delegates worker-iteration orchestration into
workers, and the splash-screen dialog loop, HWND ownership, and bitmap setup
now live in `src/platform_windows/windows_splash.cpp` instead of
`src/main.cpp`,
while `App::rec_loop()` now delegates worker-iteration orchestration into
the retained recording bridge, `App::update_rec_frames()` now delegates
recording label refresh through that same retained recording path, and the
canvas state-management cluster for picking, clear/clear-all, layer