Tracking Issue: Improve the NumberInput widget UX

[henryksloan]

The NumberInput widget should support more common ways of modifying numerical widgets, namely:

• Dragging left/right to adjust the value (Allow NumberInput value to be dragged and right-click/escape to abort the drag #1468)
• When dragging, Shift slows it down by adjusting the next order of magnitude of less precision and Ctrl snaps to increments of the current order of magnitude of precision (Allow NumberInput value to be dragged and right-click/escape to abort the drag #1468)
• When dragging, Escape and right click abort the change (Allow NumberInput value to be dragged and right-click/escape to abort the drag #1468)
• Add an integrated label to be shown on the left side, with the value on the right side, instead of the default value-centered display
• Math in the number input boxes #1471
• While editing the number field, Up/Down arrows should increment/decrement by 1 and Shift+Up/Down by 10
• Holding down the mouse button on the arrow to change it multiple times; this should probably work like key repeat, with an initial delay and a constant rate of repetition
• Hover mouse over it to copy and paste value
• Hover mouse over and hit Backspace to reset the value to its default
• Hover mouse over and hit - to negate the current value
• Hover mouse over it and hit Enter key to start editing (like clicking)
• Hover mouse over it and hit / to set the value to its reciprocal
• Hover mouse over it and Ctrl+scroll wheel to increment/decrement the value
• Detect and clean up floating point imprecision with numbers like 123.450000000000003 or 0.9999999999997 using a heuristic to convert those to 123.45 and 1.0.
• Precision issues with values greater than JS's Number.MAX_SAFE_INTEGER (9007199254740991) which is still less than Rust's u64. Typing certain values like 9007199254740995 and 9007199254740997 both get turned into nearby values like 9007199254740995 for some but not all values. This means we need to use bigint more consistently throughout the entire pipeline in the frontend.
• Unit conversions in the input boxes, blocked on Real-world units of measure #586

[piersdeseilligny]

May I suggest that in addition to Hover mouse over it and Ctrl+scroll wheel to increment/decrement the value there should also be Hover mouse over it and scroll horizontally (with trackpad or horizontal scroll wheel) to increment/decrement the value?

[Keavon]

We can certainly make it work with the horizontal wheel while holding Ctrl, however it is too dangerous to accidentally disrupt values just while scrolling around the interface. Perhaps clicking the input, then horizontally scrolling, would be another acceptable alternative that requires some explicit interaction to avoid accidental disruption.

[makoConstruct]

yeah, having Draggy Number Fields would be really important to me.

Some thoughts regarding that; it's best implemented with pointer warping (or, pointer pinning), so that the mouse pointer doesn't move while the button is held down and the value is being dragged, this allows the user to drag it as far in any direction as they want without being worried about hitting the edge of the screen and stalling out, and it's also mildly beneficial for the mouse to remain where it is just in itself, as the direction the user wants to drag the value in doesn't really meaningfully correlate with where they're going to want the mouse pointer to be once they're done dragging, and often, due to grouping related UIs in the same place, they're going to want it to be pretty much where it started.

I just went looking, and it seems like that is actually supported in web browsers now, which is neat. https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Lock_API
It causes an ugly popup, but I'm sure users will be appreciative of it.

[Nikita-str]

@Keavon

• Unit conversions in the input boxes:
  Maybe make unit input as another dropdown list element?
  | ← value → | unit |
  And in case when it can have only one unit value then it would be unchangeable div? And if there no units, just value, then hide the unit element?
  But in the same time if user write units values in value field then parse it ... if it's just value unit(e.g. 10mm) then change unit value, but if it's an expression(e.g. 10mm+20px) then leave units the same and make conversion by multiply(e.g. our units is px and expr is 10mm+20px then make it 10 * 3.779 + 20 there we suppose that 1mm is 3.779px). About multiply: can we always do it? In graphic case seems yes, in general case no (F° → C°) and if it would be needed we can substitute sub-expr to the formula and then again use current parser: (10+15)F + 10C → {C = (F - 32)*(5/9)} → ((10+15) - 32)*(5/9) + 10

• From Hover mouse over it to copy and paste value to Hover mouse over it and hit / ...:
  It can be occasional hoverover, but when user use ctrl it's more expected that action would done on hovered object. Or is the point of the features that the action done by one hand? In case of ctrl+C/ctrl+V feature we can not distinguish action with ctrl and without it because the action itself implies ctrl key, so I unsure about 9th feature. Also [ctrl]+[-] (11th feature) already has binding action(scale down) so in case of ctrl it unexpected behavior too.

• Detect and clean up floating point imprecision (15th):
  Maybe also add attribute for the precision of value?