-
Notifications
You must be signed in to change notification settings - Fork 29.8k
Add padding options to SearchAnchor
#152508
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
Add padding options to SearchAnchor
#152508
Conversation
…chor-padding-config
…or-padding-config
…ios80/flutter into feature/search-anchor-padding-config
|
@QuncCccccc I made |
Piinks
left a comment
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.
Two important questions here:
- Can a user use the Padding widget to achieve the same effect as viewBarPadding?
- Can a user use the Padding widget to achieve the same effect as viewPadding?
If they can, we might not want to complicate the API by adding more ways to aceive the same effect.
| /// If null, the value of [SearchViewThemeData.padding] will be used. | ||
| final EdgeInsets? viewPadding; |
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.
These names should match.
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 don't think they should. This field is on SearchAnchor, but that referenced theme object is for the SearchView.
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 property can help provide some space between the edge of the view and the edge of the screen for better visuals, so when the screen is small, the view has a way to not touch the screen edge. This is why we want to create this property, right? I think we can add some doc for the use case:)
|
|
||
| /// The padding to use for the search view. | ||
| /// | ||
| /// Has no effect if the search view is full-screen. |
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 would padding not affect the view by making it smaller?
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.
The padding is disabled if the view is full screen because the search view is supposed to fill the entire screen
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 also think maybe we don't need this special handle because we don't really have any specs for this property and its default behavior. Even though I can't think of a concrete use case, I just feel we can still use this property to make the "full-screen" view looks smaller? If users don't want to use it in full-screen mode, they can set the padding to zero, but the current implementation seems always dismiss this property. Just feel a conflict between two property(isFullScreen and this property) is not super ideal:)
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.
If users don't want to use it in full-screen mode, they can set the padding to zero
This would require the users to know if the view wants to make itself fullscreen or not. The view does this based on the platform.
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 just feel we can still use this property to make the "full-screen" view looks smaller
I agree. This is a common behavior. For example, the Viewport of a ScrollView will size itself smaller when wrapped with padding.
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.
AFAICT, this part of the PR is what remains to resolve before it lands.
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 would require the users to know if the view wants to make itself fullscreen or not. The view does this based on the platform.
How should we deal with this? I only want the padding to apply to the non-fullscreen view, and manually checking the platform to determine if the view will be full screen or not seems pretty clunky.
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 only want the padding to apply to the non-fullscreen view
Why though? I would expect the behavior to be the same in either situation. Having special cases baked in makes it harder for the user to understand what is happening and how to get the results they want. :)
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 though?
Because I only added the padding to have the search view not touch the bottom of the window on desktop web browsers.
Having special cases baked in makes it harder for the user to understand what is happening and how to get the results they want. :)
There is already a special case built in to show the full screen view based on the platform... I didn't even know the view did that until it was brought up in PR review, but now that I do know (and see my app behave that way on mobile browsers) I do not want the padding to apply to the full screen view.
Changing the padding if the view is full screen requires internal implementation knowledge of SearchAnchor which is not a good developer UX at all.
| this.padding, | ||
| this.barPadding, |
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.
These names should definitely match the ones on the widget that they apply to.
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.
They match the existing naming conventions of other properties in this file to the best of my knowledge
Where would these Padding widgets go? I don't see any builders for the search view. |
QuncCccccc
left a comment
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.
Sorry for the late response. Left some comments below. Please let me know if there's any questions:)
| MaterialStateProperty<BorderSide?>? barSide, | ||
| MaterialStateProperty<OutlinedBorder?>? barShape, | ||
| MaterialStateProperty<EdgeInsetsGeometry?>? barPadding, | ||
| EdgeInsets? viewBarPadding, |
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 think this is a little bit extra because we've already have barPadding above. Currently the barPadding doesn't apply to the bar in the search view, so we probably can remove this parameter and add
viewBarPadding: barPadding?.resolve(<WidgetState>{}),
in _SearchAnchorWithSearchBar constructor so that both search bars are synced.
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.
The default barPadding and viewBarPadding do NOT match, which is why I created this property in the first place. I do not think we can consolidate these.
|
|
||
| /// The padding to use for the search view. | ||
| /// | ||
| /// Has no effect if the search view is full-screen. |
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 also think maybe we don't need this special handle because we don't really have any specs for this property and its default behavior. Even though I can't think of a concrete use case, I just feel we can still use this property to make the "full-screen" view looks smaller? If users don't want to use it in full-screen mode, they can set the padding to zero, but the current implementation seems always dismiss this property. Just feel a conflict between two property(isFullScreen and this property) is not super ideal:)
| /// If null, the value of [SearchViewThemeData.padding] will be used. | ||
| final EdgeInsets? viewPadding; |
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 property can help provide some space between the edge of the view and the edge of the screen for better visuals, so when the screen is small, the view has a way to not touch the screen edge. This is why we want to create this property, right? I think we can add some doc for the use case:)
Sounds like the answer to the questions then is no? That's all I wanted to know so that we don't introduce unnecessary API surface. :) |
89b276d to
bbceb28
Compare
This comment was marked as spam.
This comment was marked as spam.
|
@QuncCccccc @Piinks what's the next step here? |
| child: SearchBar( | ||
| autoFocus: true, | ||
| constraints: headerConstraints ?? (widget.showFullScreenView ? BoxConstraints(minHeight: _SearchViewDefaultsM3.fullScreenBarHeight) : null), | ||
| padding: WidgetStatePropertyAll<EdgeInsetsGeometry?>(effectiveBarPadding), |
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 wait I spoke maybe a little too soon, was the prior behavior that SearchBar was not provided any padding? It looks like SearchBar.padding then was by default 16.0 horizontally. Is the change to 8 here breaking?
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.
Does this not make the default 8?
flutter/packages/flutter/lib/src/material/search_anchor.dart
Lines 1590 to 1591 in 50a190c
| MaterialStateProperty<EdgeInsetsGeometry>? get padding => | |
| const MaterialStatePropertyAll<EdgeInsetsGeometry>(EdgeInsets.symmetric(horizontal: 8.0)); |
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.
Yes, what I was pointing out is that is not the current default. Why is the default changing in this PR?
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 know the default padding is different between the base SearchBar and the SearchBar in the SearchView. Let me try and untangle this.
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.
Actually... That code snippet I sent is from the current main branch. So the current default is already 8.
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.
The value of 16 is passed in here:
| padding: barPadding ?? const MaterialStatePropertyAll<EdgeInsets>(EdgeInsets.symmetric(horizontal: 16.0)), |
I don't think this behavior has changed
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.
The code is really confusing with this. It definitely tripped me up for a while when I was working on it.
…nfig' into feature/search-anchor-padding-config
…or-padding-config
QuncCccccc
left a comment
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. Sorry for the late response.
|
@Piinks are you happy with the state of this? |
Piinks
left a comment
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! Thanks for your patience. A lot of us have been traveling the last month.
LGTM
Cherry-picked padding changes from #148856
Adds padding configuration options to
SearchAnchor. This PR adds the following:viewBarPadding: The padding for items inside theSearchBarin theSearchAnchorviewviewPadding: The padding to use around the entireSearchAnchorviewWorking towards #148852
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.