Repository navigation
[Bugfix] Keep the editor's menu bar when SwiftUI installs its own - #156
Merged
Merged
Conversation
Since untoldengine#153 the editor is a SwiftUI App, for the space the Apple Vision Pro preview shows, with its menus still built by the AppKit delegate. SwiftUI installs a menu bar of its own from its default commands; on macOS 26 it does so after the delegate has set the editor's, and the bar then reads Edit, View, Window and Help: no File menu, none of the editor's View items, and the app menu named after the Info.plist. On macOS 27 the editor's menu survived, which is why the change was not seen before the merge. EditorMainMenuKeeper installs the editor's menu and watches the application's main menu; whenever another menu replaces it, the editor's is put back on the next turn of the run loop (logged once). Five tests on the real NSApplication, one of them showing that without the keeper another menu stays.
Putting the editor's menu back by KVO did not hold on macOS 26: SwiftUI keeps the bar it installed. The keeper no longer replaces that NSMenu; it moves the editor's menus into whatever bar is installed, takes the bar's own items out, drops the delegate that fills it in, and keeps the Window menu the editor's. It looks again when the main menu changes and after every event the application handles (NSApplication.didUpdate, didBecomeActive, NSWindow.didBecomeKey), so it does not depend on the setter being observable. Nine tests, on a bar installed before, one installed later, one refilled in place without a setter, one that fills itself in through its delegate.
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
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.
What happened
Since #153 the editor is a SwiftUI
App, so that it can declare the space the Apple Vision Pro preview shows, while its menus are still built by the AppKit delegate at launch. SwiftUI installs a menu bar of its own from its default commands. On macOS 26 it does so after the delegate has set the editor's, and the bar then readsUntold Engine Studio · Edit · View · Window · Help: no File menu, none of the editor's View items, the app menu named after the Info.plist. On macOS 27 the editor's menu survives whatever happens after launch (checked 8 s in, after activation, after the Settings scene, after asking for the preview), which is why the change was not seen before the merge.The fix
EditorMainMenuKeeper(Editor/Window/) does not fight over whichNSMenuis the main menu. It moves the editor's menus into whatever menu bar is installed, takes that bar's own items out, drops the delegate that fills it in, and keeps the Window menu the editor's, so SwiftUI keeps the object it installed and the user sees the editor's menus. It looks again whenever the main menu changes and after every event the application handles (NSApplication.didUpdate,didBecomeActive,NSWindow.didBecomeKey), so it depends neither on the setter being observable nor on winning a replace war.AppDelegatekeeps one instead of assigningNSApp.mainMenudirectly.The first commit put the editor's own
NSMenuback through KVO; that did not hold on macOS 26, so the second commit takes the approach above.Verification
EditorMainMenuKeeperTests: nine tests on the realNSApplication: a bar installed before the editor's menus, one installed later, one refilled in place without a setter running, one that fills itself in through its delegate, the Window menu, and one showing that without the keeper another bar stays.The menu bar was replaced; the editor's menus are put back.