[christmas-countdown] Four of ten settings are read by neither the plugin nor the core

[ChuckBuilds]

Plugin

• Plugin id: christmas-countdown
• Plugin version: 1.0.2

Describe the bug

Four of the plugin's ten configuration settings do nothing:

Setting	Default	Schema says
transition.type	redraw	One of redraw, fade, slide, wipe, dissolve, pixelate
transition.speed	2	"Transition speed (1=slow, 10=fast)"
transition.enabled	true	"Enable or disable transitions"
high_performance_transitions	false	"Use high-performance transitions (120 FPS) instead of standard (30 FPS)"

manager.py is 615 lines and the string transition does not appear in it once, nor does high_performance.

I checked the core before concluding, in case transitions were a display-controller feature the plugin merely declared. They are not: every occurrence of "transition" under LEDMatrix/src/ is a comment about plugin state-machine transitions or Vegas-mode cycle boundaries. Nothing reads a transition config key, and there is no implementation of fade, slide, wipe, dissolve or pixelate anywhere.

Why it matters

The web UI presents a six-value dropdown and two more switches, all with descriptions promising specific visual behaviour. Choosing any of them changes nothing, with no warning and no log line — the most confusing possible failure mode, and 40% of this plugin's settings.

How I verified

Rendering with each of the six transition.type values produces byte-identical output:

frames=1: 1 distinct of 6
    9fbfca281f ['redraw', 'fade', 'slide', 'wipe', 'dissolve', 'pixelate']

A single frame cannot show an animation, so that alone would not be conclusive — which is why I went to the source rather than stopping there.

Suggested fix

Two reasonable paths, and the choice is yours:

1. Remove the four settings from config_schema.json. Nothing can break, since no configuration using them works today. This is a schema removal so it would want a major bump, but the practical risk is nil.
2. Implement them, if transitions between plugin screens are wanted — in which case it probably belongs in the core display controller rather than per-plugin, so every plugin benefits.

I have documented them as non-functional in #377 rather than removing them unilaterally, since six named transition types reads like deliberate design that may be waiting on implementation rather than an accident. Happy to do the removal if you would prefer it.

[ChuckBuilds]

Found a fifth while writing the README: tree_size is read and validated but never applied.

line  57: self.tree_size = config.get('tree_size')     # assigned
line 597: if self.tree_size is not None: ...           # validated (rejects <= 0)
line 612: 'tree_size': self.tree_size                  # reported in the config dump

Those are its only three appearances. The drawing computes the tree box from panel geometry instead:

tree_width  = left_half_width - (2 * tree_margin)
tree_height = height - (2 * tree_margin)
tree_img = self._get_tree_image(tree_width, tree_height)

Rendering at 8, 16, 24, 32 and 48 gives byte-identical output — one distinct hash across all five plus unset:

9fbfca281f: [None, 8, 16, 24, 32, 48]

It is a slightly worse failure than the transition settings, because it validates the value. Setting tree_size: -5 is rejected with a warning, which is fair evidence to a user that the setting is live — and then it does nothing.

So five of ten settings on this plugin have no effect. The remaining five (enabled, display_duration, update_interval, text_color, and tree_color in its documented fallback role) all work.

Same two options as above, and I would extend either to tree_size. If you would rather it were implemented than removed, applying it is a small change — clamp tree_width/tree_height to self.tree_size when it is set.