Thanks to visit codestin.com
Credit goes to github.com

Skip to content

allow changing the paint offset of a GlowingOverscrollIndicator #55829

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
May 14, 2020
Merged

allow changing the paint offset of a GlowingOverscrollIndicator #55829

merged 3 commits into from
May 14, 2020

Conversation

nioncode
Copy link
Contributor

@nioncode nioncode commented Apr 28, 2020

Description

This is an implementation of my idea outlined in #12033 (comment) to use the existing OverscrollIndicatorNotification to change the position where the glow of GlowingOverscrollIndicator is drawn.

At the moment, the glow is always drawn at offset 0 of the scrolling view, which is wrong when using a CustomScrollView with a SliverAppBar, since then the glow is drawn behind the SliverAppBar instead of below. The recommendation in the docs is to change to NestedScrollView, but NestedScrollView behaves differently in various situations compared to a CustomScrollView (e.g. #46028 (comment)) so this might not always be the right solution.

I thought about two possible solutions for this:

  1. Add leadingPaintOffset and trailingPaintOffset to GlowingOverscrollIndicator and pass them in top-down when instantiating it. This however means we have to also modify ScrollBehavior to take the same arguments so that it can use them when creating the GlowingOverscrollIndicator. The downsides of this approach are described by @Piinks in Android overscroll glow is in wrong place when using SliverAppBar #12033 (comment)

  2. With this PR, the already existing OverscrollIndicatorNotification gets extended to provide a paintOffset member that can be used to change the position of the glow. To change the position of the glow, simply wrap the CustomScrollView in a NotificationListener and modify the notification's paintOffset as shown in the docs. I feel this is less of a change to the current API and does not require a change to ScrollBehavior.

@Piinks what do you think about this approach?

Related Issues

Would solve #12033, which is only closed now with the recommendation to use NestedScrollView instead of CustomScrollView.

Tests

I added a new test for verifying that leading and trailing offsets can be modified and that they correctly follow the scroll of the container.

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I signed the CLA.
  • I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I updated/added relevant documentation (doc comments with ///).
  • All existing and new tests are passing.
  • The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
  • I am willing to follow-up on review comments in a timely manner.

Breaking Change

Did any tests fail when you ran them? Please read Handling breaking changes.

  • No, no existing tests failed, so this is not a breaking change.
  • Yes, this is a breaking change. If not, delete the remainder of this section.
    • I wrote a design doc: https://flutter.dev/go/template Replace this with a link to your design doc's short link
    • I got input from the developer relations team, specifically from: Replace with the names of who gave advice
    • I wrote a migration guide: Replace with a link to your migration guide

@fluttergithubbot
Copy link
Contributor

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@fluttergithubbot fluttergithubbot added the framework flutter/packages/flutter repository. See also f: labels. label Apr 28, 2020
@goderbauer
Copy link
Member

/cc @Piinks

@Piinks
Copy link
Contributor

Piinks commented May 1, 2020

Hey @nioncode! Thanks for following up with a PR! I will take this out for a test drive tomorrow, first glance looks like you found a really interesting way to solve the problem! I noticed you found some cases where the NestedScrollView does not always line this up right, so this may help solve that as well!

@Piinks Piinks added a: quality A truly polished experience f: scrolling Viewports, list views, slivers, etc. c: new feature Nothing broken; request for a new capability a: fidelity Matching the OEM platforms better d: api docs Issues with https://api.flutter.dev/ d: examples Sample code and demos documentation f: material design flutter/packages/flutter/material repository. labels May 1, 2020
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.

I am really excited about this. Well done. This is an elegant solution that does not appear to me to have any of the complications we discussed in the original issue. ScrollBehavior, ScrollPhysics, the required glow color parameter, etc. don't need to be bothered with, and the sample you provided to implement this is simple and easy to understand.

I think this can be used further to address the edge cases in the NestedScrollView so that developers can use both options. :)

I'd like to recommend some doc changes and also ping @goderbauer and @HansMuller who I discussed the original issue with. They may be interested in taking a peek.

I look forward to seeing some tests. Thank you! This is really great.

@nioncode
Copy link
Contributor Author

nioncode commented May 3, 2020

@Piinks thanks for the review, I updated the documentation and reworded it a bit, please let me know what you think.

There are two things that I feel should be improved:

  1. Explain in the documentation, why you might want to use NestedScrollView instead of the NotificationListener or why you might not want to switch to NestedScrollView. As a user, I'm given two options without any reasoning which one to prefer and why. Honestly, I'm not even sure what the recommendation should be, since I don't understand the exact differences of NestedScrollView and CustomScrollView, but I always try to use CustomScrollView personally, because I don't understand NestedScrollView's overscroll behavior with SliverAppBars.

  2. While this patch solves the problem for the glow position, other widgets are still drawn in the 'wrong' position. E.g. if you use a Scrollbar around your CustomScrollView, the handle gets drawn on top of the SliverAppBar instead of offsetting it to appear below it. Maybe we should think about how we can solve this problem also for Scrollbar (are there more widgets that might be affected by this?), because Scrollbar does not use OverscrollNotification and it would be weird to have different concepts for handling this in different widgets, or not?

@Piinks
Copy link
Contributor

Piinks commented May 6, 2020

All good points, let's see if I can address each of them.

  1. Explain in the documentation, why you might want to use NestedScrollView instead of the NotificationListener or why you might not want to switch to NestedScrollView. As a user, I'm given two options without any reasoning which one to prefer and why. Honestly, I'm not even sure what the recommendation should be, since I don't understand the exact differences of NestedScrollView and CustomScrollView

This is a great idea to provide this guidance. The immediate big difference between the two is that CustomScrollView is a single scrollable widget, and takes sliver children. A NestedScrollView is made up of two different scrollables, with sliver children in the outer scrollable, and box children in the inner body. NSV is often used when creating TabViews. It really depends on what someone is creating that informs which they would use. But I think we can definitely discuss this in the documentation.

but I always try to use CustomScrollView personally, because I don't understand NestedScrollView's overscroll behavior with SliverAppBars.

Do you mean the glowing overscroll or the iOS overscroll? If you mean the iOS overscroll behavior of NSV, I actually just landed a fix for that! (See #55069).

  1. While this patch solves the problem for the glow position, other widgets are still drawn in the 'wrong' position. E.g. if you use a Scrollbar around your CustomScrollView, the handle gets drawn on top of the SliverAppBar instead of offsetting it to appear below it. Maybe we should think about how we can solve this problem also for Scrollbar (are there more widgets that might be affected by this?), because Scrollbar does not use OverscrollNotification and it would be weird to have different concepts for handling this in different widgets, or not?

This is a separate issue, #13253. It looks like @LongCatIsLooong is working on it.

It does look like there is a merge conflict here that will need to be wrapped up. Otherwise I think it is lookin' good.

@nioncode
Copy link
Contributor Author

nioncode commented May 6, 2020

Do you mean the glowing overscroll or the iOS overscroll? If you mean the iOS overscroll behavior of NSV, I actually just landed a fix for that! (See #55069).

No, I was referring to the actual overscroll of the content area as shown in this post (with example gif for the differences between CustomScrollView and NestedScrollView).

This is a separate issue, #13253. It looks like @LongCatIsLooong is working on it.

Thanks for the reference. I was just wondering if it makes sense to use the same approach for both issues. Currently, adjusting the GlowingOverscrollIndicator requires using the NotificationListener, while modifying the Scrollbar gets solved with a different scrollbar widget. Maybe I'm over-complicating things though and having those separate concepts is perfectly fine?

It does look like there is a merge conflict here that will need to be wrapped up. Otherwise I think it is lookin' good.

I just rebased on latest master and resolved the conflict in the AUTHORS file.

I'll follow up with some tests during the next days since you seem to be willing to accept this :)

@nioncode
Copy link
Contributor Author

nioncode commented May 6, 2020

@Piinks actually I just implemented the tests, since it was easier than expected (thanks to the cool canvas mocking).

Could you please have a look if the assertions make sense, since I was not sure how specific the assertions around the different canvas calls should be.

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.

Flutter_LGTM
Thank you for the contribution! 🎉
It looks like there is a merge conflict in the authors file, once resolved we can land this! :)

@fluttergithubbot fluttergithubbot merged commit 362a557 into flutter:master May 14, 2020
@nioncode nioncode deleted the glowNotification branch May 17, 2020 08:38
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 31, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
a: fidelity Matching the OEM platforms better a: quality A truly polished experience c: new feature Nothing broken; request for a new capability d: api docs Issues with https://api.flutter.dev/ d: examples Sample code and demos f: material design flutter/packages/flutter/material repository. 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.

5 participants