-
Notifications
You must be signed in to change notification settings - Fork 29.8k
Tab bar improvements #63683
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
Tab bar improvements #63683
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. |
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.
Although it is nice to be able to apply padding to the custom indicator, but i think the correct solution is not to clip even without the padding. Does it make sense to somehow allow over painting the shadow outside of the tab bar? cc @HansMuller or @shihaohong ?
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 need to handle where insets > original rect, it may become native rect
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 need to handle where insets > original rect, it may become native rect
A few assert statements should fix this, i guess. I'll get to it.
Edit: Or should throw some kind of Exception.
I do know all I need to check is if the rect.size is smaller than insets.collapsedSize
I just need to know if I should just assert this or throw an exception. Exception seems a better way to me.
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.
throw a flutter error makes more sense because this is a user define value.
I was looking for a way to be able to do that, but I think the way this works is that TabBar draws a Canvas according to the space available to it, and then the indicator is being painted on that.(This is what my understanding of the code says, I might be wrong here.) Painting outside the canvas is obviously a no-no. Could there be a way to be able to increase the size of canvas? That seems like an odd way to solve this because, I think its hard to ever know how big it should be. What do you think about this? Please let me know. |
|
@chunhtai I suggested increasing the size of the padding to prevent clipping of the shadows in the original issue itself -- Would applying a shadow outside of the boundaries be a valid approach? I was under the assumption that the clipping is expected because the shadow itself "did not fit" into the provided rect, and painting outside of the boundaries of the rect goes against Flutter's layout system since we should not expect any painting to happen outside the rect itself. |
The other way will be making the shadow part of size calculation, but that maybe a big breaking change, and may be unwanted in different use cases. That being said, I think this pr is good just by the fact that we can now pad custom indicator. |
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.
throw a flutter error makes more sense because this is a user define value.
|
@chunhtai Throwing a FlutterError if |
|
This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold.For more guidance, visit Writing a golden file test for Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
|
@emem365 Sorry for the delay. Yes this need a test. Can you try to see if you can verify the indicatorRect when the indicatorPadding is applied? |
|
Ok sure. I'll try to work on this asap |
|
@chunhtai In these tests, I give the indicator property of TabBar, which takes a Decoration object, a box decoration with a color, as this would cover the entire space available for the indicator. I set some values for the indicatorPadding and then expected to find a a rect being painted with the given padding applied. Similar tests already existed for indicatorPadding being tested against UnderlineIndicator, ie, the default indicator. |
|
@emem365 For some reason I keep thinking I have reviewed this PR, sorry for the delay again. Instead of changing the existing test description, can you make the new test name more descriptive and indicate that it is testing for custom indicator? |
|
There seems to be some conflict and you may need to rebase off latest master to fix the test failures. Otherwise, this looks good to me except for the test description. |
@chunhtai No worries. I understand it must be quite overwhelming with so many issues and PRs
Sure, that makes sense. I'll rebase and change the names soon |
|
Hey @chunhtai, |
chunhtai
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
|
Thanks 🙌 |
Description
This PR adds the ability to add padding to user defined indicators in TabBar. Earlier, the TabBar used to ignore indicatorPadding for user-defined indicators.
To be specific, what I have done is, take this indicatorPadding property and pass it down to the _IndicatorPainter, this way, I apply the padding to the Rect inside which the CustomPainter is going to paint the indicator.
Also, UnderlineTabIndicator, takes in a
insetsparameter, which is set toindicatorPadding, and this is really where the indicatorPadding was originally being used. This parameter used to ignoreEdgeInsets.topandEdgeInsets.bottomfrom the indicatorPadding. Since I added indicatorPadding to the _IndicatorPainter class, it basically meant that the padding would be applied twice if it is still passed to UnderlineTabIndicator. Therefore, for the time-being, I have commented the line that passes the parameter, while creating the widget(Line-830)(If this feels like a good solution, we can just remove the line). I would really like a maintainers outlook on whether or not I should do this, and figuring out what else we could do if not this.Related Issues
Tests
Added tests for indicatorPadding being checked for both LTR and RTL text directions. Also added both the test using directional padding, ie, using STEB instead of LTRB.
In these tests, I give the indicator property of TabBar, which takes a Decoration object, a box decoration with a color, as this would cover the entire space available for the indicator. I set some values for the indicatorPadding and then expected to find a a rect being painted with the given padding applied.
Screenshot
To reproduce the behaviour, copy the contents of this gist inside main.dart of a new flutter project.
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.