I attempted to preserve the "don't draw unless different" by ditching rounding for more
precise display_span, but that didn't work. An alternative solution would be
to draw on adjustment change if there's text, since then we need to redraw
regardless of slider position, but it seemed weird even just with respect to
the slider, so I opted for this, which really definitely redraws when the
adjustment changes, period.
If this proves to be a performance issue we'll have to figure that out.
for one, it can mess up the value when switching to
numeric-entry. It is also rather useless and not
Fader-like (faders are not scrollbars).
Besides, "stepvalue" is way to large and causes jumps
(sometimes step-value is even negative, see
"fast lookahead limiter", "release time"
-> some other bug)
This cleans up a lot of false-positives in static analysis
and also helps compilers to optimize code paths in general.
(tagging the fatal stingstream operator as ‘noreturn’ is
far less trivial)
Prepare to allow BarController (with Spinbutton) to translate
internal/interface values for the SpinBox.
(The change is irrelevant for the fader/slider itself which
always use the [user-]interface value)
* change API to hide unity/default value line
* allow to override vertical scroll [1]
* allow changing button event forwarding [2]
[1] override scrolling in track-headers
[2] dbl-click is needed for BarControllers -> switch to SpinBtn
but a plain Slider on a track-header should not forward
these events to the TAV (they may trigger name-edit)
* update reserve so that round corners don't overlap
* draw complete 1px outline
* add API to hide/show the unity line
* don't show unity line at either end
* allow to shrink when the font-scaling changes
