• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

HSF / phoenix / 34687725852
49%
master: 38%

Build:
Build:
LAST BUILD BRANCH: main
DEFAULT BRANCH: master
Ran 12 Sep 2026 10:13AM UTC
Jobs 1
Files 59
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

12 Sep 2026 10:05AM UTC coverage: 48.798% (+0.08%) from 48.718%
34687725852

push

github

EdwardMoyse
feat(event-display): put "Color by" first and color at random from a seed

The color options menu showed the collection's color swatch and a "Random"
button above the "Color by" selector, so the controls for a single color sat
outside the mechanism which shows only the configs of the selected option. The
selector now comes first, and the collection color is grouped under its own
option, so it appears only when it is chosen - as the charge and momentum
controls already did.

Picking a color no longer selects the collection color option. That was safe
only while the swatch sat above the selector, as a saved state applies its
configs in file order and the selector, coming after, had the last word.
With the selector first, restoring a state colored by charge would have applied
charge and then had the stored swatch flip the option back and repaint the
collection, which is the fault in #1023 the other way round. The swatch instead
repaints only while its option is selected, and is hidden otherwise, so it
cannot be reached out of turn.

Coloring at random is now an option to color by rather than a button which
painted over whatever was selected. It is seeded, with the seed kept on the
selector so that it is restored before the option is applied: the same seed
gives the same colors, so a saved random coloring comes back as it was, and the
"Random" button re-rolls it. It previously wrote one arbitrary object's color
into the swatch, which was then all that was saved, so reloading painted the
whole collection that single color. Colors are picked by hue rather than in
RGB, which keeps objects distinguishable from each other and from the
background.

Both options are offered for every collection, as neither needs anything of the
event data.

`group` is no longer restored from a saved state, joining `hidden` which it is
derived from. A state written by an older version of Phoenix groups the
collection color and "Random" differently, or not at all.

Co-Authored-By:... (continued)

877 of 2121 branches covered (41.35%)

Branch coverage included in aggregate %.

29 of 29 new or added lines in 2 files covered. (100.0%)

1 existing line in 1 file now uncovered.

3326 of 6492 relevant lines covered (51.23%)

204.15 hits per line

Coverage Regressions

Lines Coverage ∆ File
1
31.03
2.69% packages/phoenix-event-display/src/managers/three-manager/color-manager.ts
Jobs
ID Job ID Ran Files Coverage
1 34687725852.1 12 Sep 2026 10:13AM UTC 59
48.8
GitHub Action Run
Source Files on build 34687725852
  • Tree
  • List 59
  • Changed 3
  • Source Changed 3
  • Coverage Changed 3
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Repo
  • Github Actions Build #34687725852
  • 80c17815 on github
  • Prev Build on main (#34687245625)
  • Next Build on main (#34687884693)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc