feat: replace config button sliders icon with context usage ring; fix…

[NottheGuy007]

Summary

Replace the sliders/adjustments icon in the mobile composer's config button with a dynamic SVG progress ring that shows real‑time context window usage.

Key Features

• Circular Ring: SVG ring with centered percentage number.
• Color Coding:
  • 0–50% → Green (#22c55e)
  • 50–85% → Orange (#f97316)
  • 85–100% → Red (#ef4444)
• Auto‑Reset: Ring resets to 0% (green) when a new chat session starts, fixing the stale‑value bug.
• Real‑time Updates: Syncs with token usage data after each API response.
• Accessibility: Proper ARIA labels and tooltips for screen readers.

Files Changed

• static/index.html – swapped sliders icon for the SVG ring.
• static/style.css – refined ring positioning and sizing.
• static/ui.js – added _syncMobileCtxDisplay() to update ring; included reset logic when no usage data is available.

Testing

1. Start the server and open the app in a mobile viewport.
2. The config button now displays a ring with 0.
3. After sending a few messages, the ring updates and changes color as usage grows.
4. Starting a new chat resets the ring to 0 (no leftover percentages).

[NottheGuy007]

Before:-

After:-

[nesquena-hermes]

Summary

Read the diff (3 files, +23/-1), pulled the worktree, and walked it against the existing mobile context badge implementation at static/ui.js:2520+ and static/style.css:1519-1521. The visual concept is nice — a progress ring is more glanceable than a numeric badge tucked into the corner — but the implementation has structural issues that need fixing before merge, and the diff also leaves the old badge half-deleted in a state that will confuse the next maintainer to touch this code.

Code reference

The SVG replacement at static/index.html:607:

<svg id="ctx-ring" viewBox="0 0 36 36" width="24" height="24" ...>
  <circle id="ctx-arc" cx="18" cy="18" r="14" ... stroke="#22c55e" stroke-dasharray="87.96 87.96" stroke-dashoffset="87.96" ...>
  <text id="ctx-num" ... style="...font-weight:700;fill:currentColor">0</text>
</svg>

And the update path in static/ui.js:2555-2562:

(function updateCtxRing(pct) {
  var arc = document.getElementById('ctx-arc');
  var num = document.getElementById('ctx-num');
  if (!arc || !num) return;
  var offset = 87.96 * (1 - Math.min(pct, 100) / 100);
  arc.setAttribute('stroke-dashoffset', offset);
  num.textContent = Math.round(pct);
  arc.setAttribute('stroke',
    pct <= 50 ? '#22c55e' : pct <= 85 ? '#f97316' : '#ef4444'
  );
})(state.pct);

Concerns

1. The CSS visibility-hide on the old badge is the wrong fix

static/style.css:4544 adds:

#composerMobileCtxBadge { display: none !important; }

This hides the badge unconditionally for all viewports, but the JS at ui.js:2540-2545 still sets badge.style.display='inline-flex' and writes badge.textContent, badge.classList.toggle('ctx-mid',...), etc. The element is doing computational work to render state that nobody can see. More importantly, the badge code at ui.js:2540-2545 and the new ring update code at 2555-2562 are now two parallel renderers of the same state.pct — one of them is dead but kept alive structurally. The right move is to either:

• Delete the badge entirely (composerMobileCtxBadge in index.html:608, the if(badge){...} block in ui.js, the .composer-mobile-ctx-badge styles in style.css:1519-1521), or
• Replace the badge's <span> with the ring <svg> and drive both off the same code path

Right now it's a partial migration that leaves three files with mixed states.

2. ID collision risk: ctx-ring, ctx-arc, ctx-num are not namespaced

The IDs are global to the page. Other components in the codebase use id="ctx-..."-style names in different contexts (token usage chip, model picker), and the desktop composer-footer has its own context indicator. If any later refactor lands a second context ring elsewhere on the page (e.g. a desktop equivalent), document.getElementById('ctx-arc') will return whichever element the browser parsed first. Recommend prefixing: composerMobileCtxRing, composerMobileCtxArc, composerMobileCtxNum to match the BEM-ish style already used at composerMobileCtxBadge / composerMobileCtxCompressBtn.

3. The 87.96 magic constant is fragile

87.96 is 2 × π × 14 (the circumference at r=14), hard-coded in three places: the inline SVG (stroke-dasharray="87.96 87.96"), the reset path at ui.js:2542, and the update path at ui.js:2559. If the r value in the SVG ever changes (for example to fit a different button size or to align with the larger desktop indicator), all four sites need to stay in sync or the math silently breaks.

Cleaner shape:

const CTX_RING_CIRCUMFERENCE = 2 * Math.PI * 14;  // r=14 in SVG

at the top of the file, with the SVG itself either computing stroke-dasharray from JS on first paint or accepting the constant as a documented invariant in a comment near the <circle>.

4. The reset-on-clear branch may interact with the early-return path

ui.js:2536-2544 adds the ring reset inside the if(!state||!state.visible) block. That branch's existing behavior is to hide badge and row, reset the title, and clear the compress button — all reversible UI state. The ring reset is not reversible in the same way: after this branch runs, the ring shows green/0%, but the next normal render at line 2555 will fire updateCtxRing(state.pct) and re-color it. So the reset is only briefly visible during the "no state yet" window. That's the intent per the PR body ("Auto-Reset: Ring resets to 0% (green) when a new chat session starts"), and the behavior is correct. Worth a one-line comment so a future reader doesn't think the reset is unconditional.

5. Test coverage

There are no test additions. tests/test_mobile_composer_config.py and tests/test_renderer_js_behaviour.py cover the existing mobile composer surface; one assertion that static/ui.js contains id="ctx-arc" and id="ctx-num" would catch a rename regression, similar to how tests/test_media_inline.py:55 asserts "api/media?path=" is in UI_JS.

Accessibility

The current <svg aria-hidden="true"> removes the ring from the screen-reader tree, which is intentional and correct — the parent button at index.html:606 already carries aria-label/title text that includes the context state (ui.js:2547-2549). One refinement: when the ring is in the red pct > 85 zone, the aria-label already includes the percentage via state.label, but a screen reader user wouldn't know the visual urgency tier changed. Not a blocker for this PR — would be a separate accessibility pass on the whole mobile composer.

Verdict

The visual idea is good. I'd ask for two changes before merge:

1. Pick a side on the old badge: either delete it cleanly or fold both renderers into one path. The current half-hidden state is confusing.
2. Namespace the IDs (ctx-arc → composerMobileCtxArc) to match the convention at composerMobileCtxBadge.

The 87.96 constant deduplication and the test assertion are softer asks. Once those two structural changes land I'd be happy to re-review.

[nesquena-hermes]

Triage: HOLD pending UX review — labels: hold, ux

Thanks for the change. This is a moderate-to-large visible UI change to the mobile composer (replacing the config-sliders icon with a context-usage ring), so we'd like to put it through our standard UX gate before merging:

• Multi-viewport screenshots at 390 (mobile), 768 (tablet), 1280 (compact desktop), 1440, and 1920px
• Before/after composer captures showing the icon-to-ring transition
• Verify the ring stays legible and the rotated 9px text renders cleanly on iOS Safari and Android Chrome (the SVG transform:rotate(90deg) on the <text> element is the part most likely to render unexpectedly across browsers)
• Confirm the green→orange→red transition feels right at the 50/85 thresholds vs. the previous mid/high classes (50/75)

The display:none-via-CSS dead-badge approach (#composerMobileCtxBadge { display: none !important; }) is fine for now — happy to keep that and clean it up later. Just want UX evidence before this lands.

CI was pending an action_required approval; I've kicked it (close+reopen) so the checks should populate shortly.

When you can share viewport screenshots, please post them in this PR and we'll take another look.

[NottheGuy007]

Triage: HOLD pending UX review — labels: hold, ux

Thanks for the change. This is a moderate-to-large visible UI change to the mobile composer (replacing the config-sliders icon with a context-usage ring), so we'd like to put it through our standard UX gate before merging:

• Multi-viewport screenshots at 390 (mobile), 768 (tablet), 1280 (compact desktop), 1440, and 1920px
• Before/after composer captures showing the icon-to-ring transition
• Verify the ring stays legible and the rotated 9px text renders cleanly on iOS Safari and Android Chrome (the SVG transform:rotate(90deg) on the <text> element is the part most likely to render unexpectedly across browsers)
• Confirm the green→orange→red transition feels right at the 50/85 thresholds vs. the previous mid/high classes (50/75)

The display:none-via-CSS dead-badge approach (#composerMobileCtxBadge { display: none !important; }) is fine for now — happy to keep that and clean it up later. Just want UX evidence before this lands.

CI was pending an action_required approval; I've kicked it (close+reopen) so the checks should populate shortly.

When you can share viewport screenshots, please post them in this PR and we'll take another look.

I previously added before/after mobile screenshots when opening the PR and verified the Android Chrome mobile viewport directly. At the moment I only have access to a mobile device, so I cannot currently provide native tablet/desktop viewport screenshots. Once I have access to a laptop, I can provide additional responsive viewport testing if still needed for UX review.