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
update the scrollbar that support always show the track even not on hover #90178
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. If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
1a79f49
to
2390ff0
Compare
Ready for review now |
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.
This is awesome! Thank you @xu-baolin! I am looking forward to all the changes you have laid out here and for the future. :)
I think we should avoid enumerating configs like showTrack
and showTrackOnHover
.
This sounds like a perfect use case for using a MaterialStateProperty
like ScrollbarThemeData.thumbColor
. We could simplify it to something like aMaterialStateProperty<bool?>?
for ScrollbarThemeData.trackVisibility
, that way you can evaluate showing the track for any state, or just return true for always visible etc..
In this case we would probably deprecate showTrackOnHover
and point folks to using the new property.
What do you think @xu-baolin? @HansMuller may also be interested. :)
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.
Let me know your thoughts on this. You have inspired me to see if I can refactor thickness/hoverThickness into a single MaterialStateProperty. :)
It’s weird to have a Maybe we can deprecate this after we have |
Yeah, I think when we did that large refactor last year adding RawScrollbar as the base class + new material updates, we wanted to try to make all of those changes non breaking. Since thickness already existed as a double, we just added hoverThickness. |
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.
Thanks for the updates! This is a bit tricky to refactor, so thanks for sticking with it! A cleaner API will be so much better for everyone. :)
I am happy to write dart fixes as a follow up as well.
@@ -51,8 +56,16 @@ class ScrollbarThemeData with Diagnosticable { | |||
/// * [MaterialState.hovered] on web and desktop platforms. | |||
final MaterialStateProperty<double?>? thickness; | |||
|
|||
/// Controls if the track will show in all descendant [Scrollbar] widgets. | |||
/// | |||
final MaterialStateProperty<bool?>? trackVisibility; |
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.
This should probably list the default behavior, this thickness just above here.
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.
This value defaults to null, did you mean to add some default behaviors for some platforms?
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.
By default the scrollbar will show this on hover right?
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.
Long time no see :)
I think the windows platform should show track by default.
@@ -51,8 +56,16 @@ class ScrollbarThemeData with Diagnosticable { | |||
/// * [MaterialState.hovered] on web and desktop platforms. |
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 can not found this default behavior on web or desktop platforms, am I miss something?
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.
Oh I think this hover behavior came from a design specification I was given by the material design team. If you hover over the material scrollbar on desktop the thickness changes.
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.
This is looking good. It may be helpful to include this in the design doc I mentioned in the arrow button change. That way we can reason about a follow up change to deprecate some of the other properties mentioned here.
Thanks as always for your patience. I was away. This is really good work, and a lot of it too! I know it takes a while to get through it all, that's why I think a design doc may help get us on the same page. :)
@@ -51,8 +56,16 @@ class ScrollbarThemeData with Diagnosticable { | |||
/// * [MaterialState.hovered] on web and desktop platforms. |
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.
Oh I think this hover behavior came from a design specification I was given by the material design team. If you hover over the material scrollbar on desktop the thickness changes.
@@ -51,8 +56,16 @@ class ScrollbarThemeData with Diagnosticable { | |||
/// * [MaterialState.hovered] on web and desktop platforms. | |||
final MaterialStateProperty<double?>? thickness; | |||
|
|||
/// Controls if the track will show in all descendant [Scrollbar] widgets. | |||
/// | |||
final MaterialStateProperty<bool?>? trackVisibility; |
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.
By default the scrollbar will show this on hover right?
/// If this property is null, then [ScrollbarThemeData.trackVisibility] of | ||
/// [ThemeData.scrollbarTheme] is used. If that is also null, the track will | ||
/// not show by default. | ||
final MaterialStateProperty<bool?>? trackVisibility; |
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.
Can you document how this relates (or doesn't) to showTrackOnHover
? I know that we are going to follow up with deprecating the later, but in the meantime it may be difficult to understand which one I should use and how they affect each other, or if one overrides the other.
Another thought, the
I don't know if one or the other is better necessarily, but if one sets us up better for future changes it will likely be worth it. I am curious to know what you think. Thanks @xu-baolin! |
@@ -95,6 +96,13 @@ class Scrollbar extends StatelessWidget { | |||
/// {@macro flutter.widgets.Scrollbar.isAlwaysShown} | |||
final bool? isAlwaysShown; | |||
|
|||
/// Controls if the track will show in all descendant [Scrollbar] widgets. |
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.
Why descendant Scrollbar widgets? Does this affect more than just the scrollbar widget it is set on?
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.
Oh, this is a typo.
@@ -51,6 +52,11 @@ class ScrollbarThemeData with Diagnosticable { | |||
/// * [MaterialState.hovered] on web and desktop platforms. | |||
final MaterialStateProperty<double?>? thickness; | |||
|
|||
/// Overrides the default value of [Scrollbar.trackVisibility] in all | |||
/// descendant [Scrollbar] widgets. | |||
/// |
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.
nit: remove blank line?
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.
done
8fffc99
to
c29158b
Compare
Gold has detected about 4 new digest(s) on patchset 9. |
I think what you said makes sense. For future updates, it is not suitable to introduce the Material state into Scrollbar widget. At the same time, I added some documents. |
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.
LGTM thank you!
Would you like me to do the follow-up deprecations? Or were you planning on doing that?
I am happy to do it and write the dart fix migrations if you'd prefer. :)
I would really appreciate it if you can do this for me, |
Happy to! I will cc you for review when it is ready. Thanks! :) |
I am currently working on that let the scrollbar support leading and trailing arrow buttons(reference: #80370) like chrome on the web:
First, we should support that always show the track like the web.
My arrow buttons solution (Next work):
1, Add a property like
showControlButtons
to control whether show the buttons.2, Add a class like
ArrowScrollbarButtonShape
(works like RectangularSliderTrackShape) to paint the buttons. it can be custom by the developers.Look forward to your thoughts @Piinks