Repository navigation
[Text Scaling][Material] Update BottomNavigationBar to show tooltips on long press. - #59127
Conversation
rami-a
left a comment
There was a problem hiding this comment.
LGTM but had one question and a few nits
There was a problem hiding this comment.
Nit: Since this is only used once, maybe just inline it?
There was a problem hiding this comment.
Changed to:
final MediaQueryData mediaQueryData = MediaQuery.of(context);
return MediaQuery(
// Do not grow text in bottom navigation bar because there is no room,
// instead, properly scaled tooltips will show on long press.
data: mediaQueryData.copyWith(
textScaleFactor: math.min(1.0, mediaQueryData.textScaleFactor),
),There was a problem hiding this comment.
Why is this needed? Wouldn't it be null to start with?
There was a problem hiding this comment.
It needs to be explicitly initialized because it's a final field, but I don't want to expose it in this constructor.
There was a problem hiding this comment.
Same thing here, wouldn't message already be null?
There was a problem hiding this comment.
Same as above, it needs to be explicitly initialized (because it's a final field) and I don't want to expose it in this constructor.
There was a problem hiding this comment.
Would we only want the Tooltip if the text scale factor is greater than 1?
There was a problem hiding this comment.
Guidance from design was to always include it, because it is useful for more than just text scale, for example when an item has no label.
There was a problem hiding this comment.
I dont think you need this new line
jonahwilliams
left a comment
There was a problem hiding this comment.
Does this lose the semantics service announce if a Widget is provided to a tooltip?
|
Started Google testing for this PR |
|
Google testing passed! |
goderbauer
left a comment
There was a problem hiding this comment.
Not a full review, just the solution for the issue you mentioned in the chat.
There was a problem hiding this comment.
container: true can be removed here.
|
What I noticed when playing around with this: the tooltip now also shows up when longpressing a Button in the Bar even when the textscale factor is "normal" and wouldn't require it. Is that expected? |
|
@goderbauer Good question, yes that is intentional. The idea is that Tooltips provide value in more than just the text scaling case (say, when an item has no label at all), and having the behavior be consistent will help users learn that the tooltips will reliably be there on long press. |
|
Started Google testing for this PR |
1 similar comment
|
Started Google testing for this PR |
|
Google testing passed! |
1 similar comment
|
Google testing passed! |
There was a problem hiding this comment.
I hadn't really thought about this before in other contexts, but is there any advantage in scaling down the text if it already fits?
There was a problem hiding this comment.
In this particular case, I believe that there are some users who are using textScaleFactor: 0 as a workaround to hide the labels, I do not want to break this use case. There was a period of time when BottomNavigationBar did not support hiding labels on the items.
There was a problem hiding this comment.
why are 5 seconds needed?
There was a problem hiding this comment.
They weren't needed, changed to 2 seconds, which is what the tooltip uses (there needs to be some time for the tooltip to appear).
There was a problem hiding this comment.
Maybe I'm just unfamiliar with these APIs but why do you call this in the constructor?
There was a problem hiding this comment.
markNeedsSemanticsUpdate is what triggers assembleSemanticsNode to run, and as soon as this node is created, and I wanted to make sure that method gets called. I'm also loosely following the _RenderScrollSemantics example, which adds a listener to call markNeedsSemanticsUpdate in its constructor.
It's possible that this is unnecessary. @goderbauer Do you think this call is safe to remove?
There was a problem hiding this comment.
This seems unnecessary. Newly created RenderObjects will always receive a semantics update when they first render (if semantics are turned on). What breaks if you remove this?
There was a problem hiding this comment.
Maybe add a quick comment here explaining why we have this widget and what it does to the future reader.
There was a problem hiding this comment.
This seems unnecessary. Newly created RenderObjects will always receive a semantics update when they first render (if semantics are turned on). What breaks if you remove this?
There was a problem hiding this comment.
assembleSemanticsNode only runs if semantics are turned on. Semantics are only turned on if an a11y service (e.g. TalkBack or VoiceOver) is running. I thought this label also needs to show if semantics are turned off? Based on that, I would expect that the tooltip is not showing a message when a11y services are turned off?
There was a problem hiding this comment.
Side-note: For technical reasons, a11y are always turned on when running in a simulator. Did you try the tooltip thing on a real device without having any a11y services (outside of scaling the text) enabled? You may have to force-quit and restart the app after turning the a11y service off to delete the cached label.
There was a problem hiding this comment.
Maybe we should have a separate constructor for this new feature. It may be difficult to debug if you forget to specify the message and suddenly a random string from the semantics tree appears.
There was a problem hiding this comment.
Is this because of the overlay assert you added?
There was a problem hiding this comment.
This should follow the deprecation style: https://github.com/flutter/flutter/wiki/Tree-hygiene#deprecation
There was a problem hiding this comment.
Also: Can you update the doc comment on this to mention that this property is deprecated and link to the one that should be used instead?
There was a problem hiding this comment.
Done.
Based on the breaking change guide you sent, I also created this breaking change proposal: flutter.dev/go/bottom-navigation-bar-title-deprecation, it has been open to discussion for a ~week or so now.
|
I saw you responded to the comments, but the code is still the old one. Did you by any chance forget to push? :) |
…le' param in favor of 'String label'
dd0a2de to
3c2593e
Compare
Description
This PR deprecates
BottomNavigationBarItem.title, which is aWidgetparameter, in favor ofBottomNavigationBarItem.label, which is aString.See full proposal: https://flutter.dev/go/bottom-navigation-bar-title-deprecation
Reasoning
Bottom Navigation Bars have limited space, so when the text scale factor increases, the text gets truncated.
Instead, the new Material guidance is to prevent the text in the bottom navigation bar from scaling, but then show tooltips on each item with the proper text scaling.
So, when
BottomNavigationItem.labelis used instead ofBottomNavigationBar.title, thetextScaleFactorof the bottom navigation component will be capped at 1.0, and a tooltip will be present on long press of theBottomNavigationBar.items.Additionally, the
BottomNavigationBarbuild method now asserts the presence of anOverlayancestor, as this is required to show the tooltips.Tests
I added the following tests:
labels are provided.labelsare provided.BottomAppBarverifying that text is created whenlabelparam is used.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.