ListView should not interpret the mouse wheel as flicking

I found that I couldn't access some rows of a ListView in our QML-based application, because a single click of the mouse wheel caused the ListView to auto-scroll more than a page's worth of rows. Thus some entries would start below the visible area of the list view and end up above it, with only one click.

I was able to suppress this behavior sufficiently by setting a very high flickDeceleration value, but this will reduce the control's usability in a touch UI.

The mouse wheel typically affords direct control over a scrollable container, with direction changes and indexing that happen as fast as the user spins the wheel. ListView currently subverts that control and forces the user to wait for an animated overshoot to finish playing out before being able to interact with the list again.

Flicking exists to make touch-based perusal of a list less tedious by continuing to scroll while the user lifts his finger to return to the starting point and swipe again. It also makes the list items easier to view because the user can remove his finger from the screen (which of course is not necessary with a mouse, and certainly not with a mousewheel).

We would expect the same behavior if the user were to click in the list with the mouse and then swipe and release. But it is redundant at best and defective at worst to treat a mousewheel click as a flick, because it removes valuable and expected additional behavior from this HID. In some instances, it even makes some list elements inaccessible.

In the attached video, you'll see the following list scrolling by more than a page with a single click of the wheel with default deceleration in effect:

...

Creative Cloud Files

data   <--- whizzes through the pane without stopping

Desktop    <--- whizzes through the pane without stopping

Documents

...

At the least, I suggest adding an option to not treat the mouse wheel as a flick. Thanks.