The ask
In normal app mode (a regular window, not the menu-bar popup), let the window be resized so more of each row — and more rows — fit. The fixed size was designed for the centred menu-bar popup: predictable, and never covering the whole screen. Neither reason applies to a normal window on a large display, and the Sessions tab is now dense enough (status dot, ★, badges, PR, terminal, count, time, three text lines) that width is the constraint.
Menu-bar mode stays fixed-size.
Why it is two steps, not one
Making the window resizable is small. Making it useful is the actual work: every capped line in a session row — title (60), first/last message (50/80), branch (40), last reply (80), recap (110) — is capped in characters, not pixels. A wider window would show the same text with more empty space to the right until those caps derive from the real width.
- Resizable window in normal mode —
resizable: true for that BrowserWindow, a sane minimum size, and the last bounds persisted with the other window settings so it reopens where it was. Menu-bar mode untouched. Small; src/main.ts.
- Width-aware line caps — turn the constants passed to
fitToRow(text, max) into a function of the container's width (measure once per resize, divide by an average glyph width per font size, keep the current values as the floor at the current fixed width). The six call sites already go through one helper, so this is one place. This is the step that changes what a user sees.
Step 1 without step 2 is honest to ship — more rows fit vertically at once — but should say so.
Trade-offs to keep in mind
- Layout assumptions: the search row's chips and the pinned/lists headers are
flex and cope with width; the row's right-hand cluster is flexShrink: 0, so on a narrower window it is the title that gives way — set the minimum width so that cluster never collides with the dot.
- Truncation is character-based for a reason: it is cheap, deterministic, and testable (
session-search.test.ts covers the windowing). Width-aware caps should feed the same pure functions a different max, not replace them with CSS text-overflow — the search-window behaviour ("move the window to the match") depends on knowing where the cut is.
- Two modes, one component: the switcher renders in both modes. The cap computation must fall back to today's constants when there is no measurement (first paint, menu-bar mode).
Priority
Medium. After the saved-lists / live-view PR (#147) lands; step 1 could go in any small PR, step 2 is its own.
Part of the Sessions tab work tracked in #144.
🤖 On behalf of @grimmerk — generated with Claude Code
The ask
In normal app mode (a regular window, not the menu-bar popup), let the window be resized so more of each row — and more rows — fit. The fixed size was designed for the centred menu-bar popup: predictable, and never covering the whole screen. Neither reason applies to a normal window on a large display, and the Sessions tab is now dense enough (status dot, ★, badges, PR, terminal, count, time, three text lines) that width is the constraint.
Menu-bar mode stays fixed-size.
Why it is two steps, not one
Making the window resizable is small. Making it useful is the actual work: every capped line in a session row — title (60), first/last message (50/80), branch (40), last reply (80), recap (110) — is capped in characters, not pixels. A wider window would show the same text with more empty space to the right until those caps derive from the real width.
resizable: truefor thatBrowserWindow, a sane minimum size, and the last bounds persisted with the other window settings so it reopens where it was. Menu-bar mode untouched. Small;src/main.ts.fitToRow(text, max)into a function of the container's width (measure once per resize, divide by an average glyph width per font size, keep the current values as the floor at the current fixed width). The six call sites already go through one helper, so this is one place. This is the step that changes what a user sees.Step 1 without step 2 is honest to ship — more rows fit vertically at once — but should say so.
Trade-offs to keep in mind
flexand cope with width; the row's right-hand cluster isflexShrink: 0, so on a narrower window it is the title that gives way — set the minimum width so that cluster never collides with the dot.session-search.test.tscovers the windowing). Width-aware caps should feed the same pure functions a differentmax, not replace them with CSStext-overflow— the search-window behaviour ("move the window to the match") depends on knowing where the cut is.Priority
Medium. After the saved-lists / live-view PR (#147) lands; step 1 could go in any small PR, step 2 is its own.
Part of the Sessions tab work tracked in #144.
🤖 On behalf of @grimmerk — generated with Claude Code