-
Notifications
You must be signed in to change notification settings - Fork 28.7k
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
Conversation
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. |
/cc @Piinks |
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! |
There was a problem hiding this 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.
@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:
|
All good points, let's see if I can address each of them.
This is a great idea to provide this guidance. The immediate big difference between the two is that
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).
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. |
No, I was referring to the actual overscroll of the content area as shown in this post (with example gif for the differences between
Thanks for the reference. I was just wondering if it makes sense to use the same approach for both issues. Currently, adjusting the
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 :) |
@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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Description
This is an implementation of my idea outlined in #12033 (comment) to use the existing
OverscrollIndicatorNotification
to change the position where the glow ofGlowingOverscrollIndicator
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 aSliverAppBar
, since then the glow is drawn behind theSliverAppBar
instead of below. The recommendation in the docs is to change toNestedScrollView
, butNestedScrollView
behaves differently in various situations compared to aCustomScrollView
(e.g. #46028 (comment)) so this might not always be the right solution.I thought about two possible solutions for this:
Add
leadingPaintOffset
andtrailingPaintOffset
toGlowingOverscrollIndicator
and pass them in top-down when instantiating it. This however means we have to also modifyScrollBehavior
to take the same arguments so that it can use them when creating theGlowingOverscrollIndicator
. The downsides of this approach are described by @Piinks in Android overscroll glow is in wrong place when using SliverAppBar #12033 (comment)With this PR, the already existing
OverscrollIndicatorNotification
gets extended to provide apaintOffset
member that can be used to change the position of the glow. To change the position of the glow, simply wrap theCustomScrollView
in aNotificationListener
and modify the notification'spaintOffset
as shown in the docs. I feel this is less of a change to the current API and does not require a change toScrollBehavior
.@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 ofCustomScrollView
.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.///
).flutter analyze --flutter-repo
) does not report any problems on my PR.Breaking Change
Did any tests fail when you ran them? Please read Handling breaking changes.