Status Update
No update yet.
Comments
st...@gmail.com
More suggestions:
-
Allow to override containerElevation for RichTooltipBox - RichTooltipColors has container param, but doesn't allow overriding containerElevation (which mixes color with theme primary color, resulting in undesired color)
-
Allow to set or suggest the position of shown tooltip.
-
When isPersistent=true, allow dismissing by clicking outside and still passing through the click event
For example, when some persistent tooltip is shown for a button in screen's top area, user should be able to click something else in screen without having to click twice (once to dismiss the tooltip, second time to actually dismiss the tooltip)
-
Allow to customize PlainTooltipMaxWidth/RichTooltipMaxWidth
-
Accessibility - Hard to close isPersistent=true tooltip in TalkBack mode by clicking outside (this is probably an issue with PopupWindow itself)
-
Accessibility - TalkBack says "Popup window" when tooltip is shown (might be expected)
-
M3 spec doesn't seem to allow it, but tooltip arrows would be also useful. If not added to spec, maybe expose some currently internal stuff in M4 Tooltip implementation that will allow developers to implement arrows without having to rewrite it all?
co...@google.com
It sounds like the autohide behavior you are looking for is similar to the isPersistent parameter for tooltip state:
When this is set to true, the tooltip should be able to remain on the screen until the user clicks outside of it. The request for a modifiable timeout seems reasonable to me, wdyt Kevin? Something to defer to design perhaps?
st...@gmail.com
@isPersistent = false to rememberTooltipState(). These changes might not be available yet in the current release, but it should be included in the next one. Thanks!
Plain tooltip should be used for quick descriptions, if you have a lot of text that requires longer than 1.5 seconds to read please use rich tooltip and make it actionable.
@
- I think this is a reasonable ask, will file a bug to address.
- We recently merged a change to tooltips that exposes the
PopupPositionProvider, you should be able to alter the actual position with this parameter. - You can use the
focusableparameter to achieve this flow. - Dallas What do you think about exposing the maxWidth for Plain and Rich tooltips? From my understanding, this isn't something that we normally expose.
- Yeah this is part of the
Popupimplementation. If you'd like to escalate you can file an accessibility bug with the wider compose team. - Yup, this is expected.
- This is something that we're currently working on! No exact ETA, but it would be in M3.
ma...@google.com
ap...@google.com
Branch: androidx-main
commit 6c66eb5e520994bf4f500731d2bc2e57081a89f0
Author: Kevin Truong <kevinctruong@google.com>
Date: Thu Oct 19 10:22:52 2023
[Tooltip] Adding tonalElevation and shadowElevation to APIs
Adding more flexibility to the component by allowing users to set the tonal and shadow elevation of the tooltip.
Also moving TooltipBox, PlainTooltip, and RichTooltip APIs back to experimental since they were accidentally released as stable.
Bug: 293939035
Test: N/A
Relnote: Adding tonalElevation and shadowElevation to tooltip APIs. Additionally, moving TooltipBox, PlainTooltip, and RichTooltip APIs back to experimental since they were accidentally released as stable.
Change-Id: If0f66a8ccc737a0c163fd2b2a890ce60ad3d5fe4
M compose/material3/material3/api/current.txt
M compose/material3/material3/api/restricted_current.txt
M compose/material3/material3/integration-tests/material3-demos/src/main/java/androidx/compose/material3/demos/TooltipDemo.kt
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/Tooltip.kt
na...@google.com
The main suggestion was to make the api flexible so a custom dismiss duration could be passed in when isPersistent = false and no extra logic is required. Any plans on providing that flexibility in the TooltipBox?
Description
Jetpack Compose version: 2024.02.01
Jetpack Compose component used: material3:1.2.0
Android Studio Build: N/A
Kotlin version: 1.9.22
As I was calling the bottom sheet, I was calling the colors function like this
but the latest material3 version is not providing sane defaults as it used to for the colors that I am not specifying explicitly. Instead I get black text on dark and light mode since I am not specifying a specific color for selectedTextColor and unselectedTextColor.
These lines herehttps://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/NavigationBar.kt;l=312-321?q=NavigationBarItemDefaults are the ones that probably break this behavior. Which was introduced here https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/NavigationBar.kt;l=312-321?q=NavigationBarItemDefaults
This Unspecified color is then used over here https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/NavigationBar.kt;l=445-451?q=NavigationBarItemDefaults
Interestingly, the deprecated method which says "Use overload with disabledIconColor and disabledTextColor", does seem to properly set some sane defaults for the parameters you may not be specifying.
In contrast, for NavRail this was not broken in the latest update, see herehttps://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/NavigationRail.kt;l=308-317?q=NavigationRailItemDefaults
I would expect here to get either a more sane default meaning something from the MaterialTheme which is more likely to have the right value for dark and light mode like it did before. This simply breaks the layout completely as the text is completely illegible by default.