From d80c4ea75f54e660f38976ae39a55cc0dca3cbeb Mon Sep 17 00:00:00 2001 From: Jean Date: Sun, 10 May 2026 22:44:12 +0200 Subject: [PATCH] fix(popover): avoid SwiftUI ProgressView constraint assertion Combining .scaleEffect(0.7) and .frame(width:20, height:20) on the refresh button's circular ProgressView triggers a SwiftUI runtime assertion on macOS ("maximum length doesn't satisfy min <= max" with identical operands), caused by AppKit's NSProgressIndicator returning an intrinsic size that fails strict floating-point comparison against the framed bounds. Switching to .controlSize(.small) gives the same visual reduction without conflicting size constraints. --- ClaudeMeter/Views/MenuBar/UsagePopoverView.swift | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/ClaudeMeter/Views/MenuBar/UsagePopoverView.swift b/ClaudeMeter/Views/MenuBar/UsagePopoverView.swift index 7147cd6..bd2c795 100644 --- a/ClaudeMeter/Views/MenuBar/UsagePopoverView.swift +++ b/ClaudeMeter/Views/MenuBar/UsagePopoverView.swift @@ -31,9 +31,11 @@ struct UsagePopoverView: View { } }) { if appModel.isRefreshing { + // Use controlSize rather than scaleEffect+frame: combining the latter on + // an AppKit-backed ProgressView produces a SwiftUI runtime constraint + // assertion ("max <= min" failing on equal floats) on macOS. ProgressView() - .scaleEffect(0.7) - .frame(width: 20, height: 20) + .controlSize(.small) } else { Image(systemName: "arrow.clockwise") }