Skip to content

Conversation

@moffatman
Copy link
Contributor

Increases the frictionFactor on BouncingScrollPhysics when decelerationRate = ScrollDecelerationRate.fast. This in effect reduces the friction when overscrolling. Now it's double the friction compared to ScrollDecelerationRate.normal. Previously, it was over 7 times in order to match other macOS apps. But it made it impossible to use some common Flutter interactions like RefreshIndicator. Even though this change makes it less "native", I think the experience is better.

Fixes #119702

Pre-launch Checklist

  • I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
  • I read the [Tree Hygiene] wiki page, which explains my responsibilities.
  • I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
  • I signed the [CLA].
  • I listed at least one issue that this PR fixes in the description above.
  • I updated/added relevant documentation (doc comments with ///).
  • I added new tests to check the change I am making, or this PR is [test-exempt].
  • All existing and new tests are passing.

@flutter-dashboard flutter-dashboard bot added f: scrolling Viewports, list views, slivers, etc. framework flutter/packages/flutter repository. See also f: labels. labels Mar 7, 2023
@moffatman moffatman requested a review from Piinks March 7, 2023 23:34
@moffatman moffatman force-pushed the macos_overscroll_factor branch from a527916 to 42ed7f0 Compare March 7, 2023 23:35
Copy link
Contributor

@Piinks Piinks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even though this change makes it less "native", I think the experience is better.

How different is this compared to native? Providing a native look and feel is really important to developers. I wonder, is there a change that could be made in RefreshIndicator instead? Could it check with the scroll physics to see if it should behave a little bit differently?

@goderbauer
Copy link
Member

(triage) @moffatman Do you still have plans to work on this PR and respond to the feedback given above?

@moffatman
Copy link
Contributor Author

Ran into the same issue with CupertinoSliverRefreshControl + ClampingScrollPhysics. I don't think there is any easy way to have it communicate with the physics. I will capture some videos of before/after the change compared to native

@moffatman
Copy link
Contributor Author

Look like in UIKit, when you have a UIRefreshIndicator, it makes that "segment" of overscroll easily scrollable, while applying harsh friction beyond it. Not sure if that's easily possible in flutter?

Current behaviour

  1. I can't get the flutter list to refresh without flinging (as the fling code has different friction handling).
  2. After the first "easy" UIKit scrolled section, the frictions match up, which we would lose if merging this PR.
Screen.Recording.2023-04-04.at.8.11.49.PM.mov

With this PR

  1. Doing the pull-to-refresh takes the same amount of overscroll as in UIKit
  2. After/without any refresh indicator, flutter applies relatively less friction than UIKit
Screen.Recording.2023-04-04.at.8.08.36.PM.mov

@moffatman moffatman force-pushed the macos_overscroll_factor branch from 86329d1 to 53d02fc Compare April 5, 2023 00:27
@gnprice
Copy link
Member

gnprice commented Apr 6, 2023

Look like in UIKit, when you have a UIRefreshIndicator, it makes that "segment" of overscroll easily scrollable, while applying harsh friction beyond it.

I haven't quite followed the details of the UIKit behavior you're observing, but this description sounds like the sort of thing that should be possible to express in the sliver protocol. It's a "scroll effect", where you'd be taking the distance the user has scrolled along a somewhat abstract coordinate axis, and then doing something nonlinear with it so that it has an effect more complex than literal scrolling.

Because CupertinoSliverRefreshControl is already based on a sliver, that could offer a way to get the effect you want there.

@Piinks
Copy link
Contributor

Piinks commented Apr 10, 2023

the sort of thing that should be possible to express in the sliver protocol.

Good point! I think this makes sense on the physics though. Otherwise, every sliver would have to implement this special case, or a specific sliver would have to be included wherever we would want this behavior.

Copy link
Contributor

@Piinks Piinks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for visualizing this with the scroll overlay. Very helpful! It hink it is a really nice improvement. LGTM

@Piinks Piinks added a: fidelity Matching the OEM platforms better autosubmit Merge PR when tree becomes green via auto submit App labels Apr 10, 2023
@auto-submit auto-submit bot merged commit 535b4d5 into flutter:master Apr 10, 2023
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Apr 10, 2023
exaby73 pushed a commit to exaby73/flutter_nevercode that referenced this pull request Apr 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

a: fidelity Matching the OEM platforms better autosubmit Merge PR when tree becomes green via auto submit App f: scrolling Viewports, list views, slivers, etc. framework flutter/packages/flutter repository. See also f: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Desktop] RefreshIndicator can not be dragged to its full extent

4 participants