[Date/Time Picker] Touch scroll doesn't snap to value

[amwx]

Describe the bug
After #7834, scrolling via touch can lead to an invalid state as no scroll snapping is implemented

See comment: #7834 (comment)

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. Windows, Mac, Linux (State distribution)]
• Version [e.g. 0.10.0-rc1 or 0.9.12]

Additional context
Add any other context about the problem here.

[amwx]

After attempting to fix this, I'm not so sure this has an easy fix. I've gotten snapping to work (quick tested by re-enabling the scroll bar and dragging it). But when I tested with my Surface, it doesn't work with the scroll gesture. If you swipe up/down slowly, it will jump several items and then stop there until you start a new gesture. Swiping quickly will get a better response, but still isn't fluid.

One thing I've noticed too is the gesture scroll delta is large (not sure if this play a part). I'd expect it to follow your finger, (e.g., if you tap on 12 in the day column of the DatePicker, 12 should stay under your finger - instead it will reach the end of the viewport before your finger). I looked at the handling logic in ScrollContentPresenter but I can't figure out how its all wired together - and it may be that this logic doesn't work well with modifying the offset in the middle of a scroll gesture?

I would suggest porting WinUI's scroll viewer which has better touch interaction and snapping built-in, but considering the ScrollViewer code is probably larger than the entire Avalonia codebase, that's clearly not an option.

[robloo]

I would suggest porting WinUI's scroll viewer which has better touch interaction and snapping built-in

That isn't open sourced yet, correct? I don't see it in WinUI 2. I also heard they were planning some changes for WinUI 3 but I doubt they will ever get around to it.

but considering the ScrollViewer code is probably larger than the entire Avalonia codebase

I heard that said about DataGrid some years ago. I can't think that is true for a ScrollViewer implementation though! :) It should be doable if the code exists somewhere.

A lot of Avalonia controls have reduced functionality compared to WPF or WinUI. The reason the WPF controls are larger is they support more features and edge cases can pile on code quickly. Avalonia code-base is going to have to grow without fear though and start pulling in more features. Pulling code from WPF or even WinUI shouldn't be feared as much as it is -- it actually will help everyone.

[amwx]

Technically no, the ScrollViewer isn't open sourced (yet), but it's likely successor is: see WinUI /dev/ScrollView & /dev/ScrollPresenter. They're still in "preview" but it's essentially everything that the regular ScrollViewer is with some API enhancements.

I heard that said about DataGrid some years ago. I can't think that is true for a ScrollViewer implementation though! :) It should be doable if the code exists somewhere.

I was exaggerating a little there, but ScrollView & ScrollPresenter combined is approx ~10,000 lines of c++.

[robloo]

but it's likely successor is: see WinUI /dev/ScrollView & /dev/ScrollPresenter.

Oh ok, these are the newer controls I heard about but haven't really paid attention to them. I'll have to browse through when I get a chance though. I probably missed this some time ago.

ScrollView & ScrollPresenter combined is approx ~10,000 lines of c++.

10,000 lines of C++ becomes around, what, ~7500 lines of C#? That is around three normal controls in my experience (up to ~3000 LOC for a control). Avalonia Calendar: 2125k LOC for example. Avalonia has gotten lucky (and used clever design/architecture changes) to keep extremely minimal control sizes to date but the luck is going to run out for certain controls :)

[grokys]

Could we use the ScrollGestureEndedEvent to detect when scrolling has finished and snap to the item there?

[amwx]

Could we use the ScrollGestureEndedEvent to detect when scrolling has finished and snap to the item there?

I want to say I tried that and it didn't work, but I may have messed something up. I'll try taking another look at this.

[grokys]

I think I've got a fix for this.

[grokys]

Hopefully fixed by #7964