Skip to main content

max / makeover-webview

State the constant-ratio curve answer as decided, not a shortfall
Author: Max Johnson <me@maxj.phd> · 2026-08-28 20:00 UTC
Signed with PGP, not checked
Commit: e4ea63008f995c9323003e66418baf33d80159b3
Parent: 0a5bbd6
3 files changed, +31 insertions, -20 deletions
M Cargo.toml +1 -1
@@ -1,6 +1,6 @@
1 1 [package]
2 2 name = "makeover-webview"
3 - version = "0.65.0"
3 + version = "0.65.1"
4 4 edition = "2024"
5 5 # One copy of this renderer per dependency graph, enforced by cargo rather than
6 6 # by remembering. Two versions means the generated stylesheet and the emitted
M src/form.rs +5 -5
@@ -1813,11 +1813,11 @@
1813 1813 }
1814 1814
1815 1815 #[test]
1816 - fn a_constant_ratio_curve_still_emits_a_linear_track() {
1817 - // Honest shortfall rather than a silent one: HTML has no logarithmic
1818 - // range input, so the browser draws the extent linearly. The value it
1819 - // submits is still a value in the field's own units, which is what
1820 - // every handler on this path reads. See the crate header.
1816 + fn a_constant_ratio_curve_is_answered_with_a_linear_track() {
1817 + // The decided answer, not a shortfall: HTML has no logarithmic range
1818 + // input, so the browser draws the extent linearly. The value it submits
1819 + // is still a value in the field's own units, which is what every
1820 + // handler on this path reads. See the crate header.
1821 1821 let f = Field {
1822 1822 curve: Curve::Logarithmic {
1823 1823 step: Some("0.001"),
M src/lib.rs +25 -14
@@ -221,26 +221,37 @@
221 221 //! adjacent, and what is bought is that the unit is a value a consumer can read
222 222 //! back rather than a suffix on a label it would have to parse.
223 223 //!
224 - //! # 0.54.0: a curve this renderer can carry, and one it cannot
224 + //! # 0.54.0: a curve this renderer can carry, and one it declines
225 225 //!
226 226 //! `makeover-layout` 0.32.0's `Curve`. A range takes its granularity from the
227 227 //! curve now (`Field::curve.step()`), every other kind keeps `Field::step`, and
228 228 //! `Curve::Linear` emits exactly what it emitted before.
229 229 //!
230 - //! **A constant-ratio curve still emits a linear track, and that is a
231 - //! shortfall rather than a decision.** HTML has no logarithmic range input, so
232 - //! honouring one here means either shipping JS that maps the thumb position to
233 - //! a value -- renderer-side app code, which is the thing this stack exists to
234 - //! delete -- or changing what the control submits from a value to a fraction,
235 - //! and then something has to map it on the way back in. That something is not
236 - //! this crate: the MNW server reads these forms with its own handlers, so a
237 - //! fraction arriving where a value is expected would be silent. Filed rather
238 - //! than guessed at.
230 + //! **A constant-ratio curve emits a linear track, and that is the answer, not a
231 + //! debt.** HTML has no logarithmic range input, so a described screen asking
232 + //! for one is asking the browser for something it does not have, the same class
233 + //! of request as [`makeover_layout::FieldKind::Date`] on a host with no
234 + //! calendar. The renderer answers with the nearest control the host really
235 + //! offers and keeps every fact that survives the translation: the extent, the
236 + //! granularity, and the value's own units. What does not survive is resolution
237 + //! at the small end. The value submitted is still a value in the field's own
238 + //! units, which is what every handler on this path reads.
239 239 //!
240 - //! What is not lost: the extent, the granularity, and the value's own units.
241 - //! What is lost is resolution at the small end, which is exactly the reason an
242 - //! app asked for a ratio in the first place. No consumer is affected today --
243 - //! every described range on this path is linear.
240 + //! The alternatives are worse in the specific way this stack exists to avoid.
241 + //! Shipping JS that maps thumb position to value puts app code back in the
242 + //! renderer. Changing what the control submits from a value to a fraction moves
243 + //! the mapping to whoever reads the form, and the MNW server reads these forms
244 + //! with its own handlers, so a fraction arriving where a value is expected
245 + //! would be silent.
246 + //!
247 + //! When this reopens: the day a described screen on the webview path asks for a
248 + //! non-linear range. The answer then is mapping in `quasi-router`, where one
249 + //! implementation serves every host, not JS here. Nothing asks today. No
250 + //! described screen in the tree uses a non-linear curve; the one real consumer
251 + //! is audiofiles' ADSR (`instrument_panel.rs:643`), which is egui and stays
252 + //! egui because audiofiles takes only `quasi-immediate` and
253 + //! `makeover-immediate`; and the two webview-served consumers, goingson and the
254 + //! MNW server, use no [`makeover_layout::FieldKind::Range`] at all.
244 255 //!
245 256 //! # 0.52.0: a markdown field gets the preview it was permitted
246 257 //!