0a0c7081409db2f67a8395149b54cec85a55c967
9
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  jgamboaandClaude
|
5ed029a2b8 |
Flatten the selection and the menu highlight; kill the Aero afterglow
Three things looked wrong, three different causes. The selected row carried a border. 7.css outlines tr.highlighted (#aaddfa) on top of its fill, and we had been restating that outline in the new blue — so the band had an edge, and on the cursor row the dotted focus rect made three concentric outlines around a single row. The reserved 1px border stays (it is what stops selection from shifting rows) but is transparent in every state; the fill paints under it, since background-clip is border-box. --w7-sel-bd and --w7-sel-bd-idle are gone with it. The context menu highlighted items with 7.css's translucent gradient wash — the same gradient the ListView selection just dropped. It now uses --w7-sel-bg, so selection reads identically wherever it appears. The hover-off animation was button.css bleeding into menu items, which ARE buttons: button::before is a glow overlay that fades out over a full second, and menu.css suppresses it with content:none on the :hover arm ONLY — so leaving an item brought the pseudo back with opacity animating 1 -> 0, a ghost trailing the pointer. Killing content in every state removes it. Same family, also fixed: button:focus runs pulse-anim infinitely, and this menu moves real focus between items for keyboard nav. menu-probe.ts now checks the highlight too, using hover-probe's :hover -> .simhover rewrite: it measures colour spread down a text-free strip of a force-hovered item, so "is it flat?" is a measurement. Verified the check can fail by injecting the old wash into the built stylesheet — spread 9, exit 2; the flat fill reads spread 0 at exactly #cbe8f6. The harness lost its selection outlines and nothing else, in both themes. Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
jgamboaandClaude
|
aaa12c3e23 |
Workspace tabs are a real 7.css tablist
The tab strip was a hand-rolled lookalike: bg-accent for the active tab and an absolutely-positioned bg-primary underline, competing with a tab component 7.css already ships. Replaced with its actual contract — menu[role=tablist] plus one button[role=tab][aria-selected] per workspace — so 7.css draws the joined inactive tabs and the raised white active one. Per the agreed design the per-tab X is gone: real Win7 tab controls had none, and a button nested in a button is invalid HTML. Closing keeps Ctrl/Cmd+W and gains middle-click (auxclick, guarded on button 1 so the right button never closes a tab). Drag-reorder moved onto the tab button itself and still works. Three things 7.css does that had to be accommodated, each found by looking rather than by reasoning: - Its selector is the DESCENDANT `menu[role=tablist] button`, so the +, update pill and right-hand tools deliberately stay outside the menu. - The strip is a .w7-toolbar, whose neutralizer strips background, border and both pseudo-elements to make toolbar buttons flat. That flattened the tabs to nothing, so the rule now exempts :not([role=tab]) — tabs want the full Aero slab, their neighbours want flat. - overflow-x:auto on the scroller forces computed overflow-y from visible to auto, so the strip clips vertically. 7.css raises the active tab with margin-top:-2px, which put its top border outside the scroll box and silently deleted it. The strip now reserves 2px of padding-top, mirroring the padding-left:3px 7.css already reserves for the same tab's -3px left margin. Caught by pixel-scanning the tab's top edge against 7.css's own reference markup in the harness: reference had #8e8f8f, ours jumped straight from toolbar grey to tab fill. Also: tabs.css hardcodes color:#222 on every tablist button, outside 7.css's var system, leaving labels near-invisible in dark. Routed through a new --w7-tab-c token declared light in :root.win7 and overridden in BOTH dark blocks (attribute and prefers-color-scheme), matching the ListView and menu literals. And its `display: block` outranks Tailwind's .flex, which jammed the icon against the label — flex/gap restored in skinfix. role="tabpanel" on the panel area was considered and skipped: 7.css gives it padding:14px, margin-bottom:9px and its own border, which would fight the split-pane layout for a join that cannot read anyway with the panel toolbar row in between. The harness grew a section 5 mirroring this markup, because the live app starts with exactly one workspace and there is no way to click "+" from a headless capture — multi-tab state is only checkable there. Verified in both themes headless and on a live window capture. Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
jgamboaandClaude
|
0ae2a62229 |
Stage 4a: context menu is pure 7.css; retire the lookalike and the false claim
The menu now renders 7.css's real contract — ul[role=menu] > li[role=menuitem] > button for actions, input[type=checkbox] + label for the checkable column toggles, and dividers as .has-divider on the PRECEDING item (7.css draws them as an ::after bevel, not as a node; the service's separator entries collapse onto their predecessor at render time). With the markup right, the framework supplies everything the hand-written version imitated or lacked: the left gutter stripe, bevelled separators, the gradient selection band, the checked box, and disabled/submenu styling we previously had none of. Deleted: the w7-menu lookalike (both the button-slab stripper in `skin` and the whole hand-authored Aero set in `skinfix`) and its w7-menu/w7-menu-sep hooks. The "7.css has no menu component" claims in styles.css and architecture.md were FALSE — dist/gui/menu.css is a full component; the old markup (div > button) simply matched none of it. Both corrected to state the real contract and the trap. Keyboard now follows the platform instead of a highlight class: arrows move REAL focus between items — 7.css styles :focus-visible identically to :hover, and keyboard-initiated programmatic focus counts — and Enter/Space activate buttons natively; only labels need a synthetic click. This also makes the menu honest to screen readers. Dark mode: menu.css hardcodes light literals (color:initial, white bevel halves, the #b3d3f9 checked-box ring); restated in skinfix's dark arm like the ListView's. Also fixed, caught BY the harness: the Stage 3 frame sizing rule was keyed on bare `.window`, forcing 100vh height onto every 7.css window (the harness's demo windows blew up to full page). It is now keyed on `w7-frame`, a hook only the three real window roots carry. Verified zoomed in light and dark against 7.css's reference markup: gutter, dividers, checkmark box, grey right-aligned accelerator all match; bundle 490.92 kB. Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
jgamboaandClaude
|
2294453c93 |
Stage 3a: wrap the app in 7.css's .window.glass.active frame
The app rendered a bare .title-bar with no .window around it, which is why the Aero frame, glass and drop shadow were missing and the title-bar controls sat permanently in their inactive colours: EVERY control-glyph rule in 7.css is keyed on `.title-bar.active` / `.window.active .title-bar`, and nothing ever set .active. - app.html's root is now `.window.glass`, so it picks up the 6px radius, the 1px frame, the `inset 0 0 0 1px #fff9` highlight, the drop shadow and the backdrop-filter glass layer. - The content below the title bar moved into `.window-body`, 7.css's recessed inner panel (6px inset + its own border) — the thing that gives a Win7 window its depth. - `.active` binds to a new `windowFocused` signal, seeded from document.hasFocus() and updated from window focus/blur. The webview receives those when the NATIVE window's focus changes, so no RPC is needed. Harness renders the shell focused and unfocused: active shows the red close button and crisp glyphs, inactive desaturates, matching the reference. Native window transparency (for the drop shadow and rounded corners to fall outside the window rather than being clipped by an opaque surface) is deliberately NOT in this commit — it is a native flag with a real chance of misbehaving on Linux, so it gets its own change and a real-app check. Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
jgamboaandClaude
|
2db367318d |
Stop rows shifting 2px when selected
7.css gives ONLY tr.highlighted a border (1px solid #aaddfa), and its table is border-collapse: collapse — so a selected row genuinely grew 1px at top and bottom and pushed every row beneath it down by 2px. Moving the cursor made the whole list jitter. Every tbody row now reserves that 1px as a transparent border, so selecting a row changes colour and nothing about the geometry. The rule has to live in `skinfix`, which outranks `skin` by LAYER regardless of specificity — so a blanket transparent border there also blanks 7.css's own highlight border. Both selected states therefore restate border-color explicitly: the inactive pane via --w7-li-bd-hl (the same #aaddfa 7.css uses, and already restated by the dark palette), the focused pane via --w7-el-bd-h. Added a "selection geometry" pair to the harness — identical tables, one with a middle row selected — so the baselines either line up or they visibly do not. They did not before this change; they do now, verified zoomed. Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
jgamboaandClaude
|
66076cf1d7 |
Pane focus reads from band strength, not from the dots; cursor visible in both panes
The previous model made the dotted rectangle the de-facto focus signal: the cursor row got ONLY dots (and only in the active pane), so an unfocused pane's cursor row disappeared entirely, and selection strength was the only band difference. Wrong way around for a commander UI. Now (matching Win7 Explorer / the commander convention): - tr.highlighted = "selected via Space" OR "cursor row" — the template ORs them, so the cursor row always carries the selection band in BOTH panes. - Pane focus is what changes the band: strong Aero band (--w7-el-grad-h) in the focused pane, 7.css's own faint inactive wash in the unfocused pane — that wash IS Win7's inactive-selection colour, faint by design. - The dotted rect is demoted to what it was in Win7: a keyboard-focus marker layered ON TOP of the band, focused pane only. It is no longer the thing that tells you which pane is active. Harness now renders a focused and an unfocused pane stacked, with selected rows and a cursor row in each; verified zoomed in light and dark. Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
jgamboaandClaude
|
4102020f5c |
Fix ListView selection and cursor rendering (regressions from Stage 2)
You were right that selecting a line looked off. Three separate problems, two of them introduced by the Stage 2 dark-mode block: 1. The selection band was ERASED in dark mode. Stage 2 restated the dark surface on `table > tbody > tr > *`, i.e. on the CELLS — but 7.css paints tr.highlighted on the ROW, and a cell background paints over a row background. The selected row kept only its 1px border and no fill. The base surface now goes on `table` alone; cells stay transparent so the row band shows through. Same trap re-applies to the cell separators, which 7.css deliberately drops inside a selected row and the dark rule was re-adding. 2. The cursor rectangle was drawn PER CELL. `tr.is-cursor > *` puts a dotted outline around every cell, so the focused row rendered as a row of dotted boxes. Win7 drew one rectangle around the row — the outline belongs on the `tr`. 3. Selection was barely visible even in light, and that one is 7.css's own semantics rather than a bug: listview's `.highlighted` is Win7's *inactive* selection, a near-white wash. Win7 drew the FOCUSED pane's selection as the stronger Aero band. The table now carries `is-active` from the panel's own isActive(), and the focused pane's selection uses --w7-el-grad-h/-bd-h, which the dark palette already restates, so it recolours for free. Verified by cropping and zooming the harness screenshots in both themes rather than eyeballing a full page: full-row band, separators dropped inside it, and a single dotted rectangle on the cursor row. Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
jgamboaandClaude
|
11c3d419c7 |
Stage 2: file panels become a real 7.css ListView
The file list was a CSS grid of <div>s, so 7.css's listview component never matched a single selector and Tailwind styled the whole thing. It is now the plain <table> 7.css documents, which is what makes the Aero treatment appear. - The column header row moved OUT of its own div and INTO <thead>: 7.css makes thead position:sticky, so it stays put while the body scrolls, and it has to be inside the same table to do that. - Column widths moved from a computed grid-template-columns to <colgroup>, because 7.css sets table-layout: fixed. `gridTemplate()` is deleted. - Selection is now `tr.highlighted` (7.css's gradient band + #aaddfa border) instead of bg-primary/15. - The sort arrow was the text glyph ↑/↓ from `sortIndicator()`, which is also deleted; the sorted column is now `th.highlighted.indicator[.up]` and 7.css draws the real clip-path triangle in the header. - Row height, padding, borders and fonts now come from 7.css, so --row-h and the per-cell text/color/font utilities are gone. Two things 7.css does not cover, added in `skinfix`: - Dark mode. listview.css hardcodes light literals (#fff, #c0c1cd, #eee and a white header gradient) rather than --w7-* vars, so it does NOT follow the hand-authored dark palette — the header labels rendered invisible, dark on dark. The dark arms restate those rules; light keeps 7.css's own values. - The keyboard cursor. 7.css models selection only; Win7 drew the focused row with a dotted focus rectangle over it, which is what tells "cursor" apart from "selected" when they differ. That is `tr.is-cursor`. Verified visually this time, not just by build log: harness screenshots in both light and dark show the header gradient, sort triangle, cell separators, selection band and cursor rectangle matching 7.css's reference markup. Backend `tsc --noEmit` clean, `bun run build:ui` clean, bundle 489.83 kB (from 490.50). Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
jgamboaandClaude
|
72643051f9 |
Stage 0: headless screenshot harness for the Win7 skin
Everything about this branch's look has so far been verified by reading build
logs, which is how a fully black window got reported as a clean boot. This adds
a way to actually LOOK at the skin.
- scripts/shot.ts — renders a page with Firefox headless (already installed; no
Chromium/puppeteer download) and writes a PNG. Firefox needs a dedicated
profile, since a running Firefox locks the default one.
- ui/dev/harness.html — static gallery pairing 7.css's own documented markup
("reference") against what the app currently renders ("ours"), for the window
frame, ListView, context menu, buttons, textbox, progress bars and tabs. Lives
outside ui/src so the Angular build never sees it.
Two traps found while building it, both documented in the files:
- The composed page MUST be written into ui/dist beside the stylesheet.
Firefox's security.fileuri.strict_origin_policy blocks a file:// document
from loading CSS in another directory, and the result renders completely
unstyled — indistinguishable from "the skin is broken".
- replaceAll, not replace, for the {{STYLES}} token: the harness documents the
token in a header comment that precedes the <link>, so a first-match replace
substitutes the comment and leaves the stylesheet unlinked. This produced one
false "everything is unstyled" result before it was spotted.
What the first screenshots already confirm, visually:
- The window has no Aero frame, radius, drop shadow or glass, and its title-bar
controls sit in their inactive colours — we render a bare .title-bar with no
.window.glass.active wrapper.
- The file list gets none of the ListView treatment (header gradient, sort
indicator, cell separators, selection band) because it is a div grid.
- The context menu gets none of the menu treatment (gutter, dividers, disabled
state, real checkmarks).
- NEW, not previously predicted: `.win7 button { min-width:0; padding:
revert-layer }` — added to stop Tailwind icon buttons ballooning — also
crushes legitimate dialog push buttons well below Win7's 75x23 metrics.
- Dark mode: ListView header labels and tab labels are invisible (dark on
dark), since listview.css hardcodes light literals the dark block never
restates.
Caveat recorded in the script: Firefox is Gecko, not the WebKitGTK engine the
app ships on. Good for skin fidelity, useless for native window transparency.
Co-Authored-By: Claude <noreply@anthropic.com>
|