The previous followup fix (e9654518, then 2afb0126) only applied the bundled
INI to HelloImgui's runtime state via `imgui.load_ini_settings_from_memory`,
called from the `post_init` callback. That callback fires AFTER HelloImgui
has already:
1. loaded user prefs from disk
2. loaded imgui settings from disk (via imgui.load_ini_settings_from_disk)
3. set up the dockspace tree
By the time post_init fires, HelloImgui has already discarded the empty
on-disk INI's data and built its dock state. The load_ini_settings_from_memory
apply in post_init ended up being SILENTLY DISCARDED for [Docking][Data]
entries with orphaned DockSpace IDs.
Empirical evidence: manual launch test (sloppy.py without --enable-test-hooks)
after 2afb0126 produced a saved manualslop_layout.ini of 3072 bytes with
2 DockNode entries, but those DockNodes were created at RUNTIME, not
loaded from the bundled INI's literal IDs. The imgui core loader rejected
the literal IDs from the bundled INI because the runtime IDs didn't match.
Fix: add `_install_default_layout_pre_run_result` to App.run entry, called
BEFORE `_run_immapp_result`. It writes the bundled INI to cwd if cwd's INI
is missing/empty/small, so when HelloImgui's load_user_pref / load_ini_settings_from_disk
runs, it reads my bundled INI as the initial state. The literal DockSpace
ID 0xAFC85805 (= runtime-generated MainDockSpace 2949142533) matches,
the DockNode IDs 0x00000001/0x00000002 match (because HelloImgui restores
dock IDs from INI), and per-window DockId references apply to the matching
DockNodes.
The post_init live-session apply (imgui.load_ini_settings_from_memory) is
now mostly redundant for first-launch: HelloImgui reads the bundled INI on
its initial load. But it's still there for any edge case where HelloImgui's
load_ini_settings_from_disk reads an INI after the pre-run write somehow
fails, AND it covers the "user manually wiped cwd INI mid-session" case.
Test changes:
- _assert_live_session_apply renamed to _assert_install_applied -- the
primary path is now pre-run, and the test accepts either
"[GUI] pre-run installed default layout:" or
"[GUI] installed default layout: ... (and applied to live session)"
- Updated test 1 and 2 to use the new helper name
Empirical verification (re-run of 18s manual launch):
- Before launch: cwd INI absent
- During launch: [GUI] pre-run installed default layout: ...layouts/default.ini -> ...manualslop_layout.ini
- During launch: [GUI] visible-by-default windows: AI Settings, Diagnostics,
Discussion Hub, Files & Media, Log Management, Operations Hub, Project
Settings, Response, Theme
- After force-kill: cwd/manualslop_layout.ini is 3072 bytes containing
[Docking][Data] with DockSpace ID=0xAFC85805 + DockNode ID=0x00000001
(CentralNode=1, SizeRef=481,1172) + DockNode ID=0x00000002
(SizeRef=1197,1172) + 8 [Window][...] entries with DockId=0x00000001,N or
DockId=0x00000002,N + 0 stale window names
- 17/17 tests pass
Tier 2's commit e9654518 stripped the [Docking] data block and all
per-window DockId lines from layouts/default.ini based on the wrong
theory that HelloImgui would "auto-dock" panels via its central dockspace.
Empirically verified against tier2 branch HEAD (e9654518):
manualslop_layout.ini after first launch: 1447 bytes (Docking block
with DockSpace ID=0xAFC85805 + CentralNode=1, no DockNode children,
no per-window DockId lines)
User-visible result: empty dockspace with only the menu ribbon; 9
default-visible panels are NOT rendered.
Compared with the user's working manualslop_layout.ini on master
(2150 bytes: full [Docking] hierarchy + 2 DockNode children + every
visible window has DockId=0x00000001,N or 0x00000002,N): panels render.
Root cause: the literal DockSpace ID in the bundled INI is matched by
imgui-bundle's HelloImgui against the dockspace it creates during the
session (ID computed deterministically from MainDockSpace name hash,
which is stable across sessions -- the SplitIds line in every
HelloImui-generated INI records 2949142533 = 0xAFC85805). The Phase 1
bundled INI had DockSpace ID=0xAFBEEF01 (one increment off the
correct ID) and Tier 2 stripped the entire docking structure on the
wrong theory that ids are session-incompatible. They aren't, as long as
the bundled INI's literal ID matches the runtime's computed ID.
This fix restores the docking structure in layouts/default.ini:
- 8 [Window][...] entries (Project Settings, Files & Media, AI Settings,
Theme, Operations Hub, Discussion Hub, Log Management, Diagnostics)
each with Pos + Size + Collapsed=0 AND a DockId= line referencing
0x00000001 (left column) or 0x00000002 (right column)
- [Docking][Data] block with DockSpace ID=0xAFC85805 + 2 DockNode
children (CentralNode=1 at 0x00000001 left, sibling at 0x00000002
right)
- HelloImGui_Misc block + SplitIds line
- Comment block explaining the mechanism (replaces the misleading
e9654518 "auto-dock layer" claim)
- Omits Response (in _STALE_WINDOW_NAMES from src/gui_2.py:603-607)
so _diag_layout_state does not emit a stale-name warning
The fix is the GOOD half of e9654518 -- the live-session
imgui.load_ini_settings_from_memory(src_text) apply after the copy
stays (it ensures the install takes effect on the current launch rather
than the next one). Only the INI content + the matching test
assertions change.
Tests:
- _has_docking_block_with_docknodes (replaces _has_no_docking_block):
asserts the bundled INI has [Docking][Data] with DockSpace AND
>=1 DockNode ID= line
- _every_window_has_dockid (new): asserts every [Window][...] header
is followed by a DockId= line in its block
- _has_no_stale_window_names (new): asserts no _STALE_WINDOW_NAMES
entry is in the bundled INI
17/17 tests pass (3 install + 2 reset_layout + 8 adjacent gui +
4 commands).
Empirical verification:
- delete cwd/manualslop_layout.ini
- uv run python sloppy.py (no --enable-test-hooks; without this
flag the app uses its regular GUI rendering pipeline)
- log line: "[GUI] installed default layout: ...layouts/default.ini
-> ...manualslop_layout.ini (and applied to live session)"
- log line: "[GUI] visible-by-default windows: AI Settings,
Diagnostics, Discussion Hub, Files & Media, Log Management,
Operations Hub, Project Settings, Response, Theme"
- saved manualslop_layout.ini post-launch: 3072 bytes with 2
DockNodes, 8 [Window] entries (matches bundled INI minus runtime
additions), 0 stale window names
Bundled layouts/default.ini (relocated from tests/artifacts/ in Phase 1)
contained a [Docking] data block with a hardcoded DockSpace ID 0xAFBEEF01
plus per-window DockId references to nodes 0x10 and 0x11. Those IDs were
captured at the time the layout was first generated; on any fresh session
HelloImgui computes dockspace IDs dynamically (typically a hash of the
dockspace name + creation order) so the hardcoded literal is stale by the
first render and the orphan docking instructions are silently dropped.
Result: window positions stored in the INI render the windows as
floating at their absolute Pos coordinates, but the auto-created
dockspace captures the full window body, hiding them all. User observed
empty dockspace with only the menu ribbon rendering.
Two-part fix:
1. layouts/default.ini: remove [Docking] data block and per-window DockId
lines. Comment rewritten to explain why the auto-dock strategy is the
only session-stable option. Each [Window] entry now has only Pos + Size
+ Collapsed=0, so HelloImgui's auto-dock layer places the panels as
tabs in the central dockspace on first render.
2. _install_default_layout_if_empty: after writing the bundled INI to
disk, also call imgui.load_ini_settings_from_memory(src_text) to force
the live HelloImgui session to apply the new INI. Without this, the
install only takes effect on the NEXT launch (since HelloImgui reads
cwd/manualslop_layout.ini BEFORE the post_init callback fires). With it,
first-launch panels appear immediately.
Tests:
- tests/test_default_layout_install.py assertions updated: instead of
checking for a per-window DockId line, the install now verifies (a)
[Window][Project Settings] entry exists, (b) the INI has at least one
[Window] entry, (c) the INI has no [Docking] data block.
- New _assert_live_session_apply() on tests 1 and 2 verifies the
"(and applied to live session)" log line appears in stderr, confirming
imgui.load_ini_settings_from_memory was invoked.
17/17 tests pass (3 install + 2 reset_layout + 8 adjacent gui/commands).
App._post_init now resolves src = paths.get_layouts_dir()/default.ini
and dst = Path.cwd()/manualslop_layout.ini, then calls the drain-plane
helper before the warmup-complete registration block. Errors drain to
self._startup_timeline_errors per the data-oriented convention, so a
missing bundled layout (e.g. partial wheel install) does not crash the
GUI: panels just stay invisible until the user drops a real INI in.
Test fix: test_default_layout_install._GUI_SCRIPT was a relative path,
but the subprocess Popen runs with cwd = temp_workspace where sloppy.py
does not exist. Switched to an absolute path via _PROJECT_ROOT, the
same pattern conftest.py:648 uses for the live_gui fixture.
3 tests in tests/test_default_layout_install.py per spec G6/G7 acceptance:
- test_default_layout_installed_when_ini_missing
- test_default_layout_installed_when_ini_empty
- test_default_layout_NOT_installed_when_layout_present
Currently fail as expected (no install helper exists yet). Test 3 passes as
a positive control (custom user INI is preserved when no install logic
runs).
Subprocess spawn pattern: each test creates its own tmp_path workspace,
spawns sloppy.py without --enable-test-hooks (avoids port-8999 conflict
with the live_gui session fixture's subprocess), waits 5s, terminates
via taskkill /F /T, asserts on the saved INI content.
state.toml: phase 1 marked completed; tasks t1_1-t1_10 recorded with
SHA 7577d7d. plan.md updated for Phase 1 task completion.
ed