gramps/LlamaCasty
0
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

TASK 63: the border-colour picker IS the app's own drop-down

Browse Source 
The creator (2026-10-21), on Live -> Layers -> webcam -> Properties:

  "why does the drop down under the web cam properties not show the same style for
   the border color drop down list box?"

  "one of the first things we did was define branding. We established look-and-feel
   standards. And yet you keep ignoring these and I'm wondering why"

WHY IT WAS MISSED - the answer the creator is owed.
The TASK 58 sweep had already walked the whole app for un-themed controls and the
border picker STILL was not themed, because the sweep looked for control TYPES
(ComboBox / CheckBox / TextBox) carrying no theme style - and the border picker was
NONE of those. It was a "..." Button whose Click handler built a ContextMenu of
swatches in code. It was never in the sweep's scope, and PropertiesStyleTests.cs
(a type-based guard) could not see it either. A picker that LOOKS like a drop-down
is invisible to a type-based audit; the guard has to ask "is this the app's widget?".

WHAT CHANGED
- The picker is now the app's YtComboBox - the widget the Display and Font pickers
  wear - bound to the palette (SelectedElement.BorderColorOptions) with its selection
  bound by VALUE (SelectedItem -> BorderColorEntry), because WPF's SelectedValue
  matching is ordinal and the palette mixes #FFFFFF and #e94560.
- The closed box shows the swatch + the colour's NAME; the rows show swatch + hex +
  name (the rows the creator approved in TASK 60). A ComboBox cannot do that with one
  ItemTemplate - WPF copies it into the read-only SelectionBoxItemTemplate - so
  Helpers/ClosedBoxTemplateSelector.cs picks by the ContentPresenter's templated
  parent: the ComboBox for the closed box, the ComboBoxItem for a row. Verified
  against WPF with a throwaway probe, not assumed.
- The swatch is painted by the THEME (Helpers/HexToBrushConverter.cs, registered as
  HexToBrush) - the hand-painted SolidColorBrush(Color.FromRgb(...)) in the old
  click handler was the exact anti-pattern the theme forbids. The swatch also carries
  a 1px #2a3a5e border now, so black and dark swatches are visible on the dark menu
  (the follow-up TASK 60 left open).
- The hex field stays (60px, editable): a colour outside the palette can still be
  typed, and the drop-down then carries that hex as a NAMELESS entry ("no name" is the
  honest answer). The palette's name moved out of TASK 62's TextBlock into the
  drop-down's closed box.
- The hand-built menu, its ContextMenu/MenuItem/SolidColorBrush code and
  WebcamBorderColorPicker_Click are gone.

MODEL: SceneElement.BorderColorName -> BorderColorEntry (the palette entry for the
current hex, with its name; setting it writes the hex back) + BorderColorOptions (the
palette plus the custom entry), both raised when BorderColor changes.
BorderColorPalette gains EntryFor(hex) and OptionsFor(hex); NameOf delegates.

Guards: ytLive.Tests/BorderColorPickerTests.cs (the ONE test for this change - the
model, the panel, and the REAL widget: with the app's theme style and the panel's own
templates the closed box names the colour and the rows show the hex AND the name).
The TASK 60 guard (BorderColorPaletteTests) was updated because the mechanism it
asserted - a code-built menu - no longer exists; it now guards the new wiring (the
drop-down is bound to the palette and neither the panel nor the code-behind carries a
second list of colours).

Full suite: 435/435 passed, 0 warnings.
This commit is contained in:
gramps
2026-10-21 23:09:11 -07:00
parent ef52508b1e
commit 987fddac24
19 changed files with 536 additions and 143 deletions
Download Patch File Download Diff File Expand all files Collapse all files
HANDOFF.md
+39 -11
View File
@@ -1,10 +1,11 @@
# HANDOFF — 2026-10-21 (the creator's three properties-panel asks shipped; the vv webcam Units 1+2 state below)
# HANDOFF — 2026-10-21 (the creator's properties-panel asks shipped, incl. TASK 63; the vv webcam Units 1+2 state below)
## At a glance
- **Branch** main, tracking `origin/main`. **origin/main is still `3a77662`, so five commits are
- **Branch** main, tracking `origin/main`. **origin/main is still `3a77662`, so six commits are
waiting to be pushed** (TASK 58 the theme sweep, TASK 59 the properties hierarchy, TASK 60 the
colour names, a docs commit, and TASK 61+62 the geometry field widths and the colour name beside
the hex — the creator's properties-panel asks, done in one batch). **Not pushed yet:** the push
colour names, a docs commit, TASK 61+62 the geometry field widths and the colour name beside
the hex, and TASK 63 the border-colour picker as the app's own drop-down — the creator's
properties-panel asks, done in one batch). **Not pushed yet:** the push
happens at a sub-milestone/milestone or at the creator's word ("push it") — the creator has not
said so for this batch.
- The vv feature (Units 1+2) **was** pushed at its close (2026-10-21 — the creator approved
@@ -53,6 +54,24 @@
(`SceneElement.BorderColorName`, empty for a custom hex), and the hex field keeps a fixed
width so the name stays next to the hex. The field stays editable (a custom hex can
still be typed). Guard: `ytLive.Tests/BorderColorNameTests.cs`.
- **TASK 63 - the border-colour picker IS the app's drop-down** (shipped 2026-10-21). The creator:
*"why does the drop down under the web cam properties not show the same style for the border
color drop down list box?"* and *"we established look-and-feel standards. And yet you keep
ignoring these and I'm wondering why."* **Root cause of the miss:** the TASK 58 sweep looked for
control **types** (`ComboBox`/`CheckBox`/`TextBox`) without a theme style - and the border picker
was NONE of those: it was a `...` `Button` whose `Click` handler built a `ContextMenu` in code.
It was never in the sweep's scope, and `PropertiesStyleTests.cs` (a type-based guard) could not
see it either. Now: the picker is a **`YtComboBox`** bound to the palette
(`SelectedElement.BorderColorOptions` / `BorderColorEntry`), the **closed box shows the swatch +
the colour's NAME**, the **rows show swatch + hex + name**, the hex field stays for a custom
colour, the swatch is painted by the theme's `HexToBrush` converter, and the hand-built menu +
`WebcamBorderColorPicker_Click` are **gone**. The closed box != the rows only through
`Helpers/ClosedBoxTemplateSelector.cs` (WPF copies `ItemTemplate` into the read-only
`SelectionBoxItemTemplate`; the selector is told them apart by the `ContentPresenter`'s
templated parent - `ComboBox` = closed box, `ComboBoxItem` = a row). Guard:
`ytLive.Tests/BorderColorPickerTests.cs` (model + panel + the **real widget**). The TASK 60
guard (`BorderColorPaletteTests`) was updated to guard the new wiring (the drop-down is bound to
the palette; no second list of colours anywhere).
- **The previous session (HA lights) produced NO ytLive code** — it was spent on the creator's Home
Assistant light alert system (off-repo, `192.168.50.145`). See `MyMistakes.md` → 2026-10-21: the plan
was one tweak to a verified-working script; the script was rewritten twice, the alert path broke, and
@@ -188,6 +207,11 @@ Zombie entities deleted from the registry: `script.leak_strobe`, `script.doorbel
the full top area and the circle option is not offered. **PASSES.**
## Next step
- **Creator check of TASK 63 (needs the creator's eyes)** — open Live → Layers → webcam →
Properties → Border Color: the drop-down must now LOOK like the Display/Font drop-downs (same
dark themed chrome, same chevron), the CLOSED box must show the colour's name beside the hex
field ("Crimson"), and the open list must show swatch + hex + name. The hex field still accepts a
typed colour (the drop-down then shows the swatch with no name — "no name" is the honest answer).
- **Creator check (needs the creator's hands)** — the last piece of the vv feature: switch the
resolution dropdown to "Vertical 1080p60", confirm the Live camera tile lands inside the band and
the **Circle** option (TASK 59 turned the Shape button into a Rect | Circle choice) turns the tile
@@ -202,10 +226,13 @@ Zombie entities deleted from the registry: `script.leak_strobe`, `script.doorbel
`Controls/LeftPanel.xaml` (the `SelectedElement.IsWebSource` panel, ~lines 387-402) have the
identical shape and the identical defect as the webcam's did — the Y/H fields stretch to fill the
row. Same one-line-per-field fix as TASK 61, when the creator wants it.
- **Follow-up spotted while doing TASK 60 (not fixed — out of scope for that change):** the border
colour swatches in the drop-down are a plain `Border` with the colour as `Background` and **no
border**, so the black (`#000000`) and dark swatches are nearly invisible against the dark menu
(`#16213e`). A 1px `BorderBrush="#2a3a5e"` on the swatch would fix it.
- **✅ FIXED in TASK 63:** the border-colour swatches now carry a 1px `BorderBrush="#2a3a5e"`, so
the black (`#000000`) and dark swatches are visible against the dark menu (`#16213e`).
- **Follow-up spotted while doing TASK 63 (not fixed — out of scope for that change):** the theme has
**no implicit `Button` style**, so every plain `<Button>` in the app still renders with the light
WPF system template (`Controls/LeftPanel.xaml` ×7, `Controls/CameraPickerDialog.xaml` ×2). The
border picker's `...` button was one of them and is gone; the rest are still there. A theme-level
implicit `Button` style would fix them all at once — that is a creator-queued task, not a silent edit.
- **GOG Galaxy launcher shows "offline" (2026-10-21) — GOG's own overnight outage, NOT Windows.** GOG
put `www.gog.com` behind a maintenance page (503) and their Fastly services for `auth.gog.com` /
`api.gog.com` / `remote-config.gog.com` return `500 "Fastly error: unknown domain"`; the page itself
@@ -230,9 +257,10 @@ Zombie entities deleted from the registry: `script.leak_strobe`, `script.doorbel
- TASK 55 disk hygiene (`startup.log` uncapped — 23MB and growing every 5s).
## Tests
- Last full run: **435/435 passed, 0 warnings** (2026-10-21, this session — after TASK 61's
`GeometryFieldWidthTests` and TASK 62's `BorderColorNameTests`; the runs before were 433/433 after
TASK 60, 432/432 after TASK 59 and 431/431 after TASK 58). The one failure seen earlier in the
- Last full run: **435/435 passed, 0 warnings** (2026-10-21, this session — after TASK 63's
`BorderColorPickerTests`, which replaced TASK 62's `BorderColorNameTests`; the run before was also
435/435 after TASK 61+62, and the runs before that were 433/433 after TASK 60, 432/432 after
TASK 59 and 431/431 after TASK 58). The one failure seen earlier in the
session was `LayerReorderPersistenceTests.RealMouseDrag_OnTheLayerList_PersistsTheReorder`,
which **passes in isolation** (re-run: 3/3) — the known real-mouse flake, not a regression.
- Known flaky-by-environment (all pass in isolation): `AudioPipelineTests.Mix_HonorsProviderGains…`,