The creator (2026-10-21), on Live -> Layers -> webcam -> Properties: "the Y and H boxes under webcam properties should be the same width as the X and W boxes and those widths should be fixed to accomodate the max number of possible digits providing the geometry values" "also the border color drop drown box content should also include the name of the color next to the hex value as they in the drop-down list box" TASK 61 - one fixed width for the four geometry fields. The row is a DockPanel, and WPF sizes an element to its CONTENT unless it is told otherwise, while the LAST child of a DockPanel fills the remaining space. So X/W (not last) were as wide as their text and Y/H (last) stretched across the row - two widths for the same kind of field. Now all four carry Width="44" and the rows set LastChildFill="False" (without it the last field ignores its own Width and fills anyway). 44px is the measured width of "-1920" in the app's font at 11px (the largest geometry value - the master frame is 1920x1080 - plus a sign) plus the field's padding and border. Docs: https://learn.microsoft.com/en-us/dotnet/api/system.windows.controls.dockpanel.lastchildfill The guard MEASURES the widest value with WPF's FormattedText instead of asserting a magic number, so a font change cannot silently make the field too narrow: https://learn.microsoft.com/en-us/dotnet/api/system.windows.media.formattedtext TASK 62 - the border field names its colour. SceneElement.BorderColorName carries the palette's name for the current colour ("Crimson") and is raised when the colour changes; it is EMPTY for a custom hex the creator typed, because "no name" is the honest answer. BorderColorPalette.NameOf changed to match (it used to fall back to the hex itself; the TASK 60 test assertion was updated with it). The hex field keeps a fixed width (60) so the name sits right next to the hex instead of drifting to the row's far edge - the same trap as TASK 61. Guards: ytLive.Tests/GeometryFieldWidthTests.cs, ytLive.Tests/BorderColorNameTests.cs Full suite: 435/435 passed, 0 warnings.
2.0 KiB
TASK 62 — The border-colour field shows the colour's name next to the hex
Status: ✅ Done — shipped 2026-10-21.
What it is
The creator (2026-10-21), on Live → Layers → webcam → Properties → Border Color, after TASK 60 gave the drop-down list its names:
the border color drop drown box content should also include the name of the color next to the hex value as they in the drop-down list box
So the row that shows the current colour now reads the same way the list rows do:
Border Color
[#2c3a5c] Azure [...]
How it is done
SceneElement.BorderColorName— the palette's name for the current border colour, raised wheneverBorderColorchanges. Empty for a custom hex the creator typed (there is no name for it — the field shows the hex alone).- The hex field keeps a fixed width (
Width="60"): it used to fill the row, so a name beside it would have drifted to the far edge instead of sitting next to the hex. - The name is a dimmed
TextBlock(#a0a0b0, 11px) in the same horizontal row as the field, after it — the same reading order as the drop-down list (#e94560 Crimson).
The field stays editable — the hex is still typed into it (the picker's ... button
opens the named list). Making the field read-only with a combined "#hex Name" string was
the alternative; it would have taken away typing a custom hex, so the name sits beside
the field instead.
BorderColorPalette.NameOf changed
It used to fall back to the hex itself for a colour outside the palette ("there is no name to give it"). It now returns an empty string — "no name" is the honest answer, and the caller decides what to show (the field shows the hex alone). The TASK 60 test assertion was updated with it.
Tests
ytLive.Tests/BorderColorNameTests.cs — the ONE test for this change: the model carries
the name ("Crimson") and raises it when the colour changes, a custom hex has no name, the
hex field has a fixed width, and the name sits in the same row as the field, after it.