Addressed by pull request #34, which adds examples/kaleidocycle.rs for confirmation.
Addressed by pull request #14. Benchmark measurements are recorded on the "Display benchmarking" wiki page.
As for validation, I think it becomes clearer in this model. We can discuss further Monday, but I would propose that each regulator knows how to validate a possible set point, and a text-entry…
Ergo, when you are typing in one control for the set point, the other displays of the set point (textual or graphical) should not change, as they are merely displaying the current set point;…
Whoops—I've rediscovered why the role field, or something equivalent, is needed to make regulator views act the way they currently do. This logic for determining…
In my experience, having fewer places where the same information is kept or might be perceived to be kept actually makes the code easier to understand, as well as more concise (which also helps…
And more importantly, it now seems to me that set_point_text is very likely a violation of the Model-View-Controller separation of concerns.
This field goes back to pull request #15, where it…
I am still confused as to why Regulators have a role.
Another approach I considered was changing the type of set_point to Signal<Option<f64>> and using the following logic to determine…
The pull request should be ready for review again now! I've made the following changes:
- Renamed observables to regulators
- Labeled the regulators in the outline view
