fix(panel): keep the settings orb off the event's time range - #58
Merged
Conversation
The orb is drawn in a top-trailing overlay, so it paints over whatever the content puts in that corner. On the in-progress layout that corner holds the event's time range, and nothing inset it out of the way: the orb covered the last 24pt of it, which for `14:00 - 15:00` (109pt at its font) swallowed most of the end time. `SecondaryContent` already dodged the orb with a hardcoded trailing padding; the in-progress row never got one. Shrinking the orb alone does not fix it — at 26pt it would still overlap by 18pt — so the row now insets itself as well. Both values come from `NotchPanelMetrics`, which derives the content's clearance from the orb's own size and padding, so retuning either keeps the gap intact instead of silently reintroducing the overlap. The clearance applies to the title row only; the progress bar and the elapsed/remaining labels keep the full content width.
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.
The settings gear covers the end of the event's time range on the in-progress layout.
Cause
The orb is an
.overlay(alignment: .topTrailing), so it paints over whatever the content puts in that corner — and nothing inset the content out of its way. At a 480pt panel:480 - 28= 452.padding(.trailing, 20))24pt of overlap.
14:00 - 15:00measures 109.2pt at its font, so most of the end time sat under the gear.SecondaryContentalready dodged the orb with a hardcoded.padding(.trailing, 46);InProgressContentnever got one, which is why only this layout shows the bug.Why not just shrink the orb
At 26pt the orb starts at 434, still 18pt inside the content. Size alone does not resolve it — the row has to inset too. So this does both.
What changes
NotchPanelMetrics: orb diameter, icon size, paddings, and acontentTrailingClearancederived from them rather than hardcoded. Retuning the orb now moves the clearance with it instead of silently reintroducing the overlap.Verification
Measured with AppKit at the real font (
monospacedDigitSystemFont(ofSize: 15, weight: .semibold)):The 8pt gap is structural, not text-dependent: both edges are measured from the trailing edge, so it holds for any time string and any panel width.
4 tests added on that invariant (106 total, all passing),
swiftlintclean, and the app was smoke-run fromswift run.Note
SecondaryContent's.padding(.trailing, 46)is now the odd one out — it predates the constant and is more generous than needed. Left alone deliberately: that layout is not broken, and its centred text would shift if I changed it. Worth a separate pass if you want the two unified.