Start macOS Combine benchmark tracking #231
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
SoundBlaster
deleted the
codex/execute-instructions-from-select_next.md
branch
SoundBlaster
pushed a commit
that referenced
this pull request
Nov 17, 2025
This commit addresses the bug where multiple windows of ISOInspector share a single application state, causing changes in one window to affect all other windows. Changes: - Create WindowSessionController for per-window state isolation - Each window gets its own DocumentViewModel - Each window gets its own ParseTreeStore - Each window gets its own AnnotationBookmarkSession - Window-specific load failures and export status - Refactor AppShellView to use WindowSessionController - Each view instance creates its own WindowSessionController - Window controller handles document opening and selection - App controller remains for shared state (recents, preferences) - Update ISOInspectorApp to support per-window controllers - AppShellView creates window controller in init - Add comprehensive bug report documentation - Root cause analysis of singleton pattern issue - Detailed diagnostics and testing plans - Reference architecture and implementation approach - Add unit tests for window state independence - Test that multiple windows have independent state - Test that ParseTreeStore instances are isolated - Test that DocumentViewModel instances are isolated - Test that AnnotationSession instances are isolated Architecture: - DocumentSessionController: Shared app-level state (recents, validation configs) - WindowSessionController: Per-window state (documents, tree selections, views) - Each window in WindowGroup creates its own WindowSessionController This ensures that opening different files in different windows or selecting different items maintains independent state per window. Related: Issue #231 (macOS/iPadOS multi-window state sharing)
SoundBlaster
pushed a commit
that referenced
this pull request
Nov 17, 2025
This commit addresses the bug where multiple windows of ISOInspector share a single application state, causing changes in one window to affect all other windows. Changes: - Create WindowSessionController for per-window state isolation - Each window gets its own DocumentViewModel - Each window gets its own ParseTreeStore - Each window gets its own AnnotationBookmarkSession - Window-specific load failures and export status - Refactor AppShellView to use WindowSessionController - Each view instance creates its own WindowSessionController - Window controller handles document opening and selection - App controller remains for shared state (recents, preferences) - Update ISOInspectorApp to support per-window controllers - AppShellView creates window controller in init - Add comprehensive bug report documentation - Root cause analysis of singleton pattern issue - Detailed diagnostics and testing plans - Reference architecture and implementation approach - Add unit tests for window state independence - Test that multiple windows have independent state - Test that ParseTreeStore instances are isolated - Test that DocumentViewModel instances are isolated - Test that AnnotationSession instances are isolated Architecture: - DocumentSessionController: Shared app-level state (recents, validation configs) - WindowSessionController: Per-window state (documents, tree selections, views) - Each window in WindowGroup creates its own WindowSessionController This ensures that opening different files in different windows or selecting different items maintains independent state per window. Related: Issue #231 (macOS/iPadOS multi-window state sharing)
SoundBlaster
pushed a commit
that referenced
this pull request
Nov 17, 2025
This commit fixes a critical regression introduced by the bug #231 fix (commit a7fbefd) where selecting a file for inspection would not display the box tree or report content in the UI. Root Cause: In AppShellView.swift, documentViewModel was initialized as @ObservedObject from a local variable in the init method: init(appController: DocumentSessionController) { let windowController = WindowSessionController(...) // Local variable self._windowController = StateObject(wrappedValue: windowController) self._documentViewModel = ObservedObject(wrappedValue: windowController.documentViewModel) } When the local variable goes out of scope after init, the binding chain between @ObservedObject documentViewModel and the actual source breaks, causing SwiftUI to not receive updates when documents are loaded. Solution: Convert documentViewModel from a stored @ObservedObject property to a computed property that accesses windowController.documentViewModel directly: private var documentViewModel: DocumentViewModel { windowController.documentViewModel } This ensures SwiftUI properly tracks changes through the @StateObject windowController, restoring proper UI updates. Changes: - Remove @ObservedObject stored property for documentViewModel - Add computed property that returns windowController.documentViewModel - Add comprehensive bug report documentation (Bug #232) - Document root cause analysis and solution approach Impact: - Fixes UI not displaying content after file selection - Maintains per-window state isolation from bug #231 fix - No API changes - all existing usage continues to work - Proper SwiftUI binding chain restored Related: Issue #232 (regression from #231 fix)
SoundBlaster
pushed a commit
that referenced
this pull request
Nov 17, 2025
This commit fixes a critical regression introduced by the bug #231 fix (commit a7fbefd) where selecting a file for inspection would not display the box tree or report content in the UI. Root Cause: In AppShellView.swift, documentViewModel was initialized as @ObservedObject from a local variable in the init method: init(appController: DocumentSessionController) { let windowController = WindowSessionController(...) // Local variable self._windowController = StateObject(wrappedValue: windowController) self._documentViewModel = ObservedObject(wrappedValue: windowController.documentViewModel) } When the local variable goes out of scope after init, the binding chain between @ObservedObject documentViewModel and the actual source breaks, causing SwiftUI to not receive updates when documents are loaded. Solution: Convert documentViewModel from a stored @ObservedObject property to a computed property that accesses windowController.documentViewModel directly: private var documentViewModel: DocumentViewModel { windowController.documentViewModel } This ensures SwiftUI properly tracks changes through the @StateObject windowController, restoring proper UI updates. Changes: - Remove @ObservedObject stored property for documentViewModel - Add computed property that returns windowController.documentViewModel - Add comprehensive bug report documentation (Bug #232) - Document root cause analysis and solution approach Impact: - Fixes UI not displaying content after file selection - Maintains per-window state isolation from bug #231 fix - No API changes - all existing usage continues to work - Proper SwiftUI binding chain restored Related: Issue #232 (regression from #231 fix)
SoundBlaster
pushed a commit
that referenced
this pull request
Nov 17, 2025
- Move all files from DOCS/INPROGRESS to DOCS/TASK_ARCHIVE/231_MultiWindow_State_Isolation_and_Bug_Fixes - Update ARCHIVE_SUMMARY.md with new entry documenting Bug #231, #232 (in progress), and #233 (resolved) - DOCS/INPROGRESS now empty and ready for next planning cycle Archived items: - Bug #231: macOS/iPadOS multi-window state sharing issue - Bug #232: UI content not displayed regression (critical) - Bug #233: SwiftUI publishing changes warning (resolved)
SoundBlaster
pushed a commit
that referenced
this pull request
Nov 17, 2025
- Move 233_SwiftUI_Publishing_Changes_Warning_Fix.md to DOCS/TASK_ARCHIVE/231_SwiftUI_Publishing_Changes_Warning_Fix/ - Update ARCHIVE_SUMMARY.md with entry documenting the resolved bug and fix approach - Keep Bugs #231 and #232 (IN PROGRESS) in DOCS/INPROGRESS - Keep new bug reports #234-#241 in DOCS/INPROGRESS for planning This rebase on main includes the new bug reports added to the main branch.
SoundBlaster
pushed a commit
that referenced
this pull request
Nov 18, 2025
- Move 233_SwiftUI_Publishing_Changes_Warning_Fix.md to DOCS/TASK_ARCHIVE/231_SwiftUI_Publishing_Changes_Warning_Fix/ - Update ARCHIVE_SUMMARY.md with entry documenting the resolved bug and fix approach - Keep Bugs #231 and #232 (IN PROGRESS) in DOCS/INPROGRESS - Keep new bug reports #234-#241 in DOCS/INPROGRESS for planning This rebase on main includes the new bug reports added to the main branch.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Testing
https://chatgpt.com/codex/tasks/task_e_68ec0cb2d614832198005d803f90005a