Fix rendering of the Plotter widget on initial states

[rafaellehmkuhl]

Fix #1708

[ArturoManzoli]

The plotter widget now shows up on Cockpit start, but it has no values. It says: Max: Infinity; Min: Infinity; Current: NaN.

It's already better than it was, but I think would be even better if the initial value on the plot widget was the input-Widget last value, when available. I think all input widget has that last value saved on boot

[rafaellehmkuhl]

The plotter widget now shows up on Cockpit start, but it has no values. It says: Max: Infinity; Min: Infinity; Current: NaN.

It's already better than it was, but I think would be even better if the initial value on the plot widget was the input-Widget last value, when available. I think all input widget has that last value saved on boot

Done!

[rafaellehmkuhl]

@ArturoManzoli I've added an extra thing: if there's only one value (which is the regular case for input widgets on boot), draw an horizontal line. It seems more intuitive.

[ES-Alexander]

if there's only one value (which is the regular case for input widgets on boot), draw an horizontal line. It seems more intuitive.

This could be confusing, by making it seem like there are values available (e.g. for a sensor that is actually broken / not communicating) - it would be preferable to show something like an un-filled circle at the starting position (on the left), and ideally show the current value text as NaN¹.

We could maybe generalise this by making it so any valid value followed by nothing is a filled circle, and any valid value directly followed by NaN is an empty circle, which would then help to display things like a rangefinder losing its target lock or something. That way we could just start plotters with NaN, and if they have a last recorded value then they can start with that followed by NaN (which then also makes it clear where the real values start once they begin).

Footnotes

1. I think it's fine for min/max to be set, since they don't actually require valid data points, especially given they'll likely be optionally manually controllable in future. ↩

[ArturoManzoli]

On the first cockpit boot after initializing the server, the plot widget really shows the last value, but on a F5 refresh the plot state gets back to the NaN.

Screenshare.-.2025-02-24.7_44_38.AM.mp4

[ArturoManzoli]

if there's only one value (which is the regular case for input widgets on boot), draw an horizontal line. It seems more intuitive.

This could be confusing, by making it seem like there are values available (e.g. for a sensor that is actually broken / not communicating) - it would be preferable to show something like an un-filled circle at the starting position (on the left), and ideally show the current value text as NaN1.

We could maybe generalise this by making it so any valid value followed by nothing is a filled circle, and any valid value directly followed by NaN is an empty circle, which would then help to display things like a rangefinder losing its target lock or something. That way we could just start plotters with NaN, and if they have a last recorded value then they can start with that followed by NaN (which then also makes it clear where the real values start once they begin).

Footnotes

1. I think it's fine for min/max to be set, since they don't actually require valid data points, especially given they'll likely be optionally manually controllable in future. ↩

I agree with you, and this might get a little confusing on some cases. But on general use I think it will be fine.
One quick solution I think would be to use a dashed line on the boot to show the last value as a horizontal line. Once a new value is provided to the data-lake variable, the line become solid again.

The empty circle would be mathematically more accurate, but I suppose, will require some extra hours of work

[rafaellehmkuhl]

On the first cockpit boot after initializing the server, the plot widget really shows the last value, but on a F5 refresh the plot state gets back to the NaN.

I'm trying to reproduce this problem here, but without success. Maybe it's a problem on the dial widget side?

Just tested here. It's a bug with all input widgets that are inside collapsible containers. Nothing to do with this PR, so opened #1714 to track that.

Kapture.2025-02-24.at.11.13.39.mp4

[rafaellehmkuhl]

if there's only one value (which is the regular case for input widgets on boot), draw an horizontal line. It seems more intuitive.

This could be confusing, by making it seem like there are values available (e.g. for a sensor that is actually broken / not communicating) - it would be preferable to show something like an un-filled circle at the starting position (on the left), and ideally show the current value text as NaN1.

We could maybe generalise this by making it so any valid value followed by nothing is a filled circle, and any valid value directly followed by NaN is an empty circle, which would then help to display things like a rangefinder losing its target lock or something. That way we could just start plotters with NaN, and if they have a last recorded value then they can start with that followed by NaN (which then also makes it clear where the real values start once they begin).

Footnotes

1. I think it's fine for min/max to be set, since they don't actually require valid data points, especially given they'll likely be optionally manually controllable in future. ↩

Agree with the circle solution for single and NaN values. Will implement that.

About the other ideas, regarding generalization, I think they are valuable but out of the scope of this PR, since its aimed for fixing the initial rendering, which is broken. Do you think its ok if we left those for a future PR?

[rafaellehmkuhl]

@ArturoManzoli @ES-Alexander let me know what you think would be the ideal solution. We can also mix the options, regarding circle size, dashed lines, circle position, etc. I've pushed the branch with those cases handled so you can also try changing the rendering code and see what could be the preferable solution.

Options 1 and 2 (circles on the left of the canvas, big and small):

.

Option 3 and 4 (circles in the middle of the canvas, big or small):

[ArturoManzoli]

@ArturoManzoli @ES-Alexander let me know what you think would be the ideal solution. We can also mix the options, regarding circle size, dashed lines, circle position, etc. I've pushed the branch with those cases handled so you can also try changing the rendering code and see what could be the preferable solution.

Option 1 best represents the value as a stationary number for me!

[ES-Alexander]

About the other ideas, regarding generalization, I think they are valuable but out of the scope of this PR, since its aimed for fixing the initial rendering, which is broken. Do you think its ok if we left those for a future PR?

Yeah, that's quality of life, so no worries - I've opened it as #1716 to track.

let me know what you think would be the ideal solution ... regarding circle size, dashed lines, circle position, etc.

Circle on the left definitely seems most intuitive to me. Circle size maybe best in between the current big and small options?

[rafaellehmkuhl]

@ES-Alexander @ArturoManzoli done.