When "Reduce animations" is turned on, the scroll motion animation for scrollwheel is entirely missing in the new month view
What is/isn't working
As part of issue 603, a ratcheting scroll motion animation was implemented.
- When GNOME's animations are turned on, it is visible when using the touchpad and scrollwheel (not yet keyboard, that's #1065).
- However, when "Reduce Animations" is turned on, the motion animation does not work with the scrollwheel (but it still works with the touchpad).
I believe it should work with the scrollwheel (maybe 2x faster, if desired) even when animations are turned off.
Why this matters
Loosely summarizing my thoughts from #1065 / #1079 (closed):
I think the smooth ratcheting scroll animation is fundamental for the eye to be able to "track" what goes where and avoid getting lost [...], you need the positional awareness at all times; it's very difficult to keep track of what goes where if week shifts do not use smooth motion.
It is not a random eyecandy animation, but related to the physical movement the user has triggered with their fingers (whether that happens on a touchpad, scroll wheel, or keyboard), it provides "tactile" feedback, in a way.
Maintaining the scroll motion would be consistent with other apps; using "Reduce animations" doesn't prevent scrolling from being smooth in Nautilus, Epiphany, GNOME Calendar's week view timetable, Evince, or any GTK app that scrolls contents (or tabs widgets), for example. You don't see apps like Nautilus or Evince using paging or sudden jumps from one chunk of content to another when using the scroll wheel, and Calendar's weeks rows are the content. Arguably, the only difference between other apps and GNOME Calendar is that Calendar uses a "ratchet" to auto-align the end of the scroll to the contents, but fundamentally, it's still content scrolling.
The absence of such an animation is the reason I couldn't use Evolution's week-by-week scrolling feature, it was too easy to be disoriented if there is no way for the eye to "follow" the motion.
Possible alternative behavior
I'm happy to have the same exact animation happen even if the "reduce animations" setting is enabled; alternatively, if you want the behavior to be different while "Reduce Animations" is turned on, then perhaps the animation could simply be made faster when the "reduce animations" setting is turned on, whereas it could remain more relaxed in regular mode (the current speed seems fine to me).