cocoa: re-assert applicationIconImage when switching to Regular - #116
Merged
Merged
Conversation
…olicy A menu-bar (accessory-policy) process that sets its Dock icon once at startup — before it has ever had a Dock tile to update — found that icon silently absent once a real window later switched it to Regular: the icon property itself stayed correctly set throughout (confirmed: -applicationIconImage kept reporting the right image), but the Dock tile itself showed a generic icon regardless. Apple's own DTS guidance on this exact Accessory<->Regular pattern (a Qt developer hit the same thing) says plainly that the Dock's reaction to a runtime icon change is not instant and can revert unexpectedly across a policy transition. NewWithOptions now re-sends whatever applicationIconImage is already set (a no-op if none is) right when it switches to Regular — live human-verified on a real Dock tile: absent before this change, present after, using the exact same go-macos/objc.SetApplicationIconImage call this fix does nothing to alter. Also bumps go-macos/objc to v0.10.1: SetApplicationIconImage itself had a separate load-order bug (fixed upstream) that made it a no-op as the first-ever AppKit call in a process — exactly a menu-bar app's own startup — so this repo needed that fix before the re-assert above had anything correct to re-assert in the first place. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
1 task
tannevaled
added a commit
to go-aiquota/tray
that referenced
this pull request
Sep 9, 2026
No code change needed — window.Open now re-asserts applicationIconImage when switching to Regular activation policy (go-widgets/window#116), which is what actually makes the branded Dock icon (#22) show up: the image was always set correctly internally, but the Dock tile itself needed the re-assert at the policy transition to pick it up (a known AppKit quirk per Apple's own DTS guidance on this exact pattern). Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
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
1 participant
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
A menu-bar (accessory-policy) process that sets its Dock icon once at startup — before it ever has a Dock tile to update — found that icon silently absent once a real window later switched it to Regular. The icon property itself stayed correctly set throughout (
-applicationIconImagekept reporting the right image at every step, verified), but the Dock tile showed a generic icon regardless.Apple's own DTS guidance on this exact Accessory↔Regular pattern (a Qt developer hit the same thing on the developer forums) says plainly that the Dock's reaction to a runtime icon change is not instant and can revert unexpectedly across a policy transition.
NewWithOptionsnow re-sends whateverapplicationIconImageis already set (a no-op if none is) right when it switches to Regular. Live human-verified on a real Dock tile: absent before this change, present after, using the exact samego-macos/objc.SetApplicationIconImagecall this fix does nothing to alter.Also bumps
go-macos/objcto v0.10.1:SetApplicationIconImageitself had a separate load-order bug (fixed upstream, go-macos/objc#18) that made it a no-op as the first-ever AppKit call in a process — exactly a menu-bar app's own startup — so this repo needed that fix before the re-assert above had anything correct to re-assert in the first place.Test plan
go build ./...,go vet ./...,gofmt -l .cleango test ./...(non-integration) green across every packageTestApplicationIconSurvivesAccessoryToRegularpasses-tags=integrationon-device suite otherwise green; two unrelated failures observed locally (TestLiveCocoaDragDrop, flaky — passed on retry; several screen-list tests) were caused by the local display going to sleep mid-run (Display Asleep: Yes,CGGetActiveDisplayList counted 0 displays), not by this change — deferring to CI's dedicated on-device runner for the authoritative signal🤖 Generated with Claude Code