Status Update
No update yet.
Comments
re...@lunabee.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?
cl...@gmail.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?
an...@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.
sa...@persgroep.net
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
se...@google.com
ap...@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?
se...@google.com
na...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material3:material3:1.4.0-alpha10androidx.compose.material3:material3-android:1.4.0-alpha10androidx.compose.material3:material3-jvmstubs:1.4.0-alpha10androidx.compose.material3:material3-linuxx64stubs:1.4.0-alpha10
Description
Jetpack Compose version: 1.2.0-alpha06 Jetpack Compose component used: ScrollableTabRow Android Studio Build: Android Studio Bumblebee | 2021.1.1 Patch 2 Build #AI-211.7628.21.2111.8193401 Kotlin version: 1.6.10
Our design system requires custom tab padding between tabs and for the tab minimum width to be customized. Within the
ScrollableTabRow, every tab has a constraint around a hard-coded minimum tab width, which disallows us from using the standardScrollableTabRowcomposable.See the line:
I'm proposing that
minTabWidtheither be provided as an optional parameter on theScrollableTabRowcomposable with an ability to not have a constraint set or that it hooks into the modifier.I'm also proposing that we have a separate, new
tabPaddingparameter so that we can customize the left and right padding of the view that is composed for the Tab. Currently, this is being created by theScrollableTabRowfor us and there is no way for us to customize it. It would be beneficial to allow developers to customize this.