Been running v1.4.9 with both providers on for a couple of days and hit two things that
looked like one bug at first. They're not related, so I'll write them separately.
Setup: Windows 11 Pro 10.0.19045, 1920x1080, taskbar at the bottom with small icons on,
show_codex = true.
1. The widget ends up under the weather panel
With both providers enabled the two rows looked like they were drawn on top of each
other and the Codex row was unreadable. I assumed the widget was overlapping itself,
but that's not what's happening.
The widget anchors its right edge to TrayNotifyWnd. Windows also right-aligns
DynamicContent2 — the "News and interests" / weather panel — and that one sits to the
left of the notification area and gets painted over whatever is under it.
I dumped the rects before touching anything:
ClaudeCodeUsageMonitor x = 1379..1664 (285 px)
DynamicContent2 x = 1529..1656 (127 px)
So 127 px of the widget is just covered. With a single provider the widget is narrow
enough that it never reaches that far left, which is why this only shows up once you
turn the second provider on.
Fix I'm using locally: take DynamicContent2 into account in the horizontal anchor when
it exists, and place the widget to the left of it instead of under it.
2. The weekly row is cut off the bottom of the screen
Separate problem, found after the first one was out of the way. I only ever saw one row
and figured the weekly line just wasn't rendering.
WIDGET_HEIGHT is hardcoded to 46 px. A Windows 11 taskbar with small icons is 30 px.
compute_anchor_y clamps the top of the widget to the taskbar, so the extra 16 px runs
off the bottom edge of the screen — and that 16 px is exactly where the weekly row is.
widget y = 1050..1096
taskbar y = 1050..1080
Fix I'm using: a widget_height_for(anchor_height) helper that clamps the widget to
whatever bar it's sitting in, used by both position_at_taskbar and the drag clamp.
render_layered then paints at the window's actual height instead of assuming
WIDGET_HEIGHT.
Happy to open a PR with both, or split them if you'd rather review them separately. I haven't tested anything other than a bottom taskbar on a single monitor, so the weather panel fix in particular might need a second look for vertical taskbars.
Been running v1.4.9 with both providers on for a couple of days and hit two things that
looked like one bug at first. They're not related, so I'll write them separately.
Setup: Windows 11 Pro 10.0.19045, 1920x1080, taskbar at the bottom with small icons on,
show_codex = true.1. The widget ends up under the weather panel
With both providers enabled the two rows looked like they were drawn on top of each
other and the Codex row was unreadable. I assumed the widget was overlapping itself,
but that's not what's happening.
The widget anchors its right edge to
TrayNotifyWnd. Windows also right-alignsDynamicContent2— the "News and interests" / weather panel — and that one sits to theleft of the notification area and gets painted over whatever is under it.
I dumped the rects before touching anything:
So 127 px of the widget is just covered. With a single provider the widget is narrow
enough that it never reaches that far left, which is why this only shows up once you
turn the second provider on.
Fix I'm using locally: take
DynamicContent2into account in the horizontal anchor whenit exists, and place the widget to the left of it instead of under it.
2. The weekly row is cut off the bottom of the screen
Separate problem, found after the first one was out of the way. I only ever saw one row
and figured the weekly line just wasn't rendering.
WIDGET_HEIGHTis hardcoded to 46 px. A Windows 11 taskbar with small icons is 30 px.compute_anchor_yclamps the top of the widget to the taskbar, so the extra 16 px runsoff the bottom edge of the screen — and that 16 px is exactly where the weekly row is.
Fix I'm using: a
widget_height_for(anchor_height)helper that clamps the widget towhatever bar it's sitting in, used by both
position_at_taskbarand the drag clamp.render_layeredthen paints at the window's actual height instead of assumingWIDGET_HEIGHT.Happy to open a PR with both, or split them if you'd rather review them separately. I haven't tested anything other than a bottom taskbar on a single monitor, so the weather panel fix in particular might need a second look for vertical taskbars.