Draft: Invert number spinner scroll direction
This should better match the behavior of GTK builtin number spiner and similar widgets in other toolkits.
Partially as result of discussion on rocketchat and also my own personal frustration with current behavior of the new number widgets.
The code changes are trivial, but most of the work is in actual testing and figuring out what the expected/normal behavior is.
Terminology:
- Traditional scrolling -> moving finger on scrollwheel down results in scrolling down, you see the lower part of content
- Natural scrolling -> moving finger on scrollwheel down results in scrolling up, content moves down
- Number spinner -> input widget for numbers usually with some kind of +- or up down arrows that can be clicked for increasing/decreasing number in addition to text editing
- Slider -> more abstract number input widget manipulated by dragging a handle
Native and other software behavior:
| scenario | traditional | natural scrolling |
|---|---|---|
| GTK4 Linux builtin spinner | down=decrease | down=increase |
| GTK4 Linux builtin slider | down=left/decrease | down=left/decrease |
| macOS native spinner | none | none |
| macOS native sliders | ignore | ignore |
| macOS GTK4 builtin spinner | down=decrease | down=increase |
| Windows11 classic WIN32 based UI (e.g. ContorlPanel/Power options) | down=decrease | down=increase |
| Windows11 volume slider | down=left/decrease | down=right/increase |
| Windows11 notepad font size | down=increase | down=decrease |
| Windows11 Paint font size | down=increase | down=decrease |
| Windows11 Paint statusbar zoom dropdown | down=decrease | down=increase |
| Windows11 clock timer edit | down=decrease | down=increase |
| Linux Clion spinner in settings | down=increase | down=decrease |
| Linux Qt6 spinner | down=decrease | down=increase |
| Linux Qt6 slider | down=left/down | down=left/down |
So I would say for the most part expected behavior is down=decrease/down traditional, down=increase natural scrolling.
macOS as usual sidesteps the problem by not implementing the functionality. I couldn't find any number spinner in standard builtin software, there were some sliders but they didn't react to scroll wheel. For the most part there were only dropdowns and occasional text only input fields. Scrollwheel had more or less no effect on any widget except scrolling scrollviews.
Windows was as inconsistent as it's UI frameworks. Older traditional software behaved same as Linux. Newer software which has been rewritten in Wind10/Win11 wasn't consistent even with itself, two identical looking widgets on the same screen could react in opposite ways. Technically some of those inverted behaving inputs where more of dropdowns for numbers which react to scroll events instead of proper number spinners.
Inkscape testing after changes:
| scenario | traditional | natural scrolling |
|---|---|---|
| Linux | down=decrease | down=increase |
| Linux horizontal scroll | left=decrease | left=increase |
| macOS | down=decrease | down=increase |
| windows | down=decrease | down=increase |
Other thoughts
The initial testing of how other software behaves gave big hit to my confidence about what the "normal" behavior is. Before it I would have said with confidence that in most software cases down=down and natural scrolling mostly affects only scrollviews not number inputs.