Skip to content

Conversation

@Rexios80
Copy link
Member

Cherry-picked padding changes from #148856

Adds padding configuration options to SearchAnchor. This PR adds the following:

  • viewBarPadding: The padding for items inside the SearchBar in the SearchAnchor view
  • viewPadding: The padding to use around the entire SearchAnchor view

Working towards #148852

Pre-launch Checklist

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@Rexios80 Rexios80 requested review from Piinks and QuncCccccc July 29, 2024 21:13
@github-actions github-actions bot added framework flutter/packages/flutter repository. See also f: labels. f: material design flutter/packages/flutter/material repository. labels Jul 29, 2024
@Rexios80 Rexios80 marked this pull request as draft July 29, 2024 21:31
@Rexios80 Rexios80 marked this pull request as ready for review July 29, 2024 21:32
@Rexios80
Copy link
Member Author

Rexios80 commented Aug 7, 2024

@QuncCccccc I made viewBarPadding just EdgeInsets instead of a WidgetStateProperty

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.

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.

Comment on lines 325 to 326
/// If null, the value of [SearchViewThemeData.padding] will be used.
final EdgeInsets? viewPadding;
Copy link
Contributor

Choose a reason for hiding this comment

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

These names should match.

Copy link
Member Author

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.

Copy link
Contributor

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.
Copy link
Contributor

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?

Copy link
Member Author

@Rexios80 Rexios80 Aug 8, 2024

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

Copy link
Contributor

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:)

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

@Piinks

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.

Copy link
Contributor

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. :)

Copy link
Member Author

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.

Comment on lines +47 to +48
this.padding,
this.barPadding,
Copy link
Contributor

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.

Copy link
Member Author

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

@Rexios80
Copy link
Member Author

Rexios80 commented Aug 8, 2024

Two important questions here

Where would these Padding widgets go? I don't see any builders for the search view.

Copy link
Contributor

@QuncCccccc QuncCccccc left a 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,
Copy link
Contributor

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.

Copy link
Member Author

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.
Copy link
Contributor

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:)

Comment on lines 325 to 326
/// If null, the value of [SearchViewThemeData.padding] will be used.
final EdgeInsets? viewPadding;
Copy link
Contributor

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:)

@Rexios80 Rexios80 requested a review from QuncCccccc August 16, 2024 17:31
@Piinks
Copy link
Contributor

Piinks commented Aug 16, 2024

Where would these Padding widgets go? I don't see any builders for the search view.

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. :)

@Piinks Piinks force-pushed the feature/search-anchor-padding-config branch from 89b276d to bbceb28 Compare August 26, 2024 17:48
@ciriousjoker

This comment was marked as spam.

@Rexios80
Copy link
Member Author

Rexios80 commented Sep 4, 2024

@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),
Copy link
Contributor

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?

Copy link
Member Author

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?

MaterialStateProperty<EdgeInsetsGeometry>? get padding =>
const MaterialStatePropertyAll<EdgeInsetsGeometry>(EdgeInsets.symmetric(horizontal: 8.0));

Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Member Author

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.

Copy link
Member Author

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

Copy link
Member Author

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.

@Rexios80 Rexios80 requested a review from Piinks September 17, 2024 16:47
Copy link
Contributor

@QuncCccccc QuncCccccc left a 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.

@Rexios80
Copy link
Member Author

Rexios80 commented Oct 4, 2024

@Piinks are you happy with the state of this?

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! Thanks for your patience. A lot of us have been traveling the last month.
LGTM

@Piinks Piinks added the autosubmit Merge PR when tree becomes green via auto submit App label Oct 15, 2024
@auto-submit auto-submit bot merged commit e96aaab into flutter:master Oct 15, 2024
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Oct 16, 2024
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Oct 17, 2024
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 12, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 13, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Feb 13, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Mar 6, 2025
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Mar 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

autosubmit Merge PR when tree becomes green via auto submit App f: material design flutter/packages/flutter/material repository. framework flutter/packages/flutter repository. See also f: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants