Files

T

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

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.

2026-10-21 23:09:11 -07:00

4.4 KiB

Raw Blame History

TASK 63 — The border-colour picker is the app's own drop-down

Status: ✅ Done — shipped 2026-10-21.

What it is

The creator (2026-10-21), on Live → Layers → webcam → Properties → Border Color:

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

and, with the reason:

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

So the border colour is picked with the app's own drop-down — the YtComboBox every other picker wears — instead of a ... button that built a ContextMenu in code.

Why it was missed (the root cause, recorded so it cannot recur)

The TASK 58 sweep looked for controls by type (ComboBox / CheckBox / TextBox) that carried no theme style. The border picker was none of those — it was a Button whose Click handler built a ContextMenu of swatches in code. So it was never in the sweep's scope, and ytLive.Tests/PropertiesStyleTests.cs could not see it either: the guard asserts control types, not the design system. A style sweep must ask "is this the app's widget?", not "is this control type themed?".

How it is done

The picker — a ComboBox with Style="{StaticResource YtComboBox}", bound to SelectedElement.BorderColorOptions (the palette) and SelectedItem to SelectedElement.BorderColorEntry (TwoWay). SelectedItem, not SelectedValue: WPF matches SelectedValue ordinally (case-sensitively) and the palette mixes #FFFFFF and #e94560; the model matches by VALUE, so the hex the creator typed in any case still lands on the right row.
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 the template by the ContentPresenter's templated parent (the ComboBox for the closed box, the ComboBoxItem for a row).
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 for the current colour moved out of a TextBlock (TASK 62's BorderColorName) and into the drop-down's closed box.
The swatch is painted by the theme, not by code: Helpers/HexToBrushConverter.cs (registered in Themes/Controls.xaml as HexToBrush) turns the hex into a brush, and the templates use the theme's border colour #2a3a5e so the black swatch is visible on the dark popup. The hand-built menu, its hand-painted SolidColorBrushes and WebcamBorderColorPicker_Click are gone.

The model

SceneElement.BorderColorName → BorderColorEntry (the palette entry for the current hex, with its name; setting it writes the hex back) and BorderColorOptions (the palette plus the custom entry). Both are raised when BorderColor changes.
BorderColorPalette.EntryFor(hex) (case-insensitive; a nameless entry for a colour outside the palette) and OptionsFor(hex) (the palette + that entry). NameOf now delegates to EntryFor.

Tests

ytLive.Tests/BorderColorPickerTests.cs — the ONE test for this change, in three parts: the model (the palette entry, the custom hex, the raises), the panel (the picker IS a YtComboBox over the palette, the hex field survives, the hand-rolled menu is gone from both the XAML and the code-behind) and the real widget — with the app's theme style and the panel's real templates, the closed box shows the name and the rows show the hex AND the name. ytLive.Tests/BorderColorPaletteTests.cs (TASK 60) was updated: its "the picker builds its menu from the palette" step 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).

Follow-ups (not done — out of scope)

The theme has no implicit Button style, so every plain <Button> in the app still renders with the light WPF system template (LeftPanel.xaml ×7, CameraPickerDialog.xaml ×2). The border picker's ... button was one of them; the rest are still there.
The palette's hexes keep their mixed casing (#FFFFFF vs #e94560).

4.4 KiB Raw Blame History Unescape Escape