fix: re-capture display properties after settling to fix stale working area#1346
Draft
lohrm-spf wants to merge 1 commit into
Draft
fix: re-capture display properties after settling to fix stale working area#1346lohrm-spf wants to merge 1 commit into
lohrm-spf wants to merge 1 commit into
Conversation
… working area With menu bar auto-hide enabled, macOS may briefly show the menu bar during display reconfiguration or at launch. NSScreen.visibleFrame captured at that moment includes the menu bar offset, but macOS does not fire another notification once the menu bar re-hides. This causes an unexpected gap between the top bar and tiled windows on the primary monitor. Schedule a follow-up display change event 500ms after each reconfiguration to re-capture display properties once macOS has settled. Also fire one at startup to correct any transient values from the initial capture.
lars-berger
reviewed
Apr 1, 2026
| // reconfiguration and does not fire another notification | ||
| // once it re-hides (~300-500ms later). | ||
| let tx = event_tx.clone(); | ||
| std::thread::spawn(move || { |
Member
There was a problem hiding this comment.
hmm is there a difference between this and just extending the coalesce duration 500ms..? 👀
lohrm-spf
changed the title
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
3 participants
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
NSScreen.visibleFrameonce macOS has settledProblem
With menu bar auto-hide enabled, macOS may briefly show the menu bar during display reconfiguration (monitor connect/disconnect) or at launch.
NSScreen.visibleFramecaptured at that moment includes the menu bar offset (~25-37px), but macOS does not fire anotherNSApplicationDidChangeScreenParametersNotificationonce the menu bar re-hides. The staleworking_areaoffset is then added to the user'souter_gap, creating an unexpected gap on the primary monitor.The issue is intermittent because it depends on whether the menu bar happens to be visible at capture time. It only affects the primary monitor (secondary monitors have no menu bar). Windows is unaffected because the taskbar working area is stable.
Solution
Re-use the existing delayed-event pattern (already used for wake coalescing) to schedule a follow-up
DisplaySettingsChangedevent 500ms after:visibleFramereflects the true usable areapopulate()captureThe handler (
handle_display_settings_changed) already handles redundant events gracefully — if the re-captured properties match the stored ones, the redraw is effectively a no-op.Research
NSScreenentirely, using private SkyLight/CG APIs for menu bar geometryNSApplicationDidChangeScreenParametersNotification(same as GlazeWM) but subscribes to additional menu bar change notificationsNSScreenon every refresh session