Fixed
Status Update
Comments
ch...@google.com <ch...@google.com> #2
Hi. Thanks for reporting this. Fixed in alpha-04
jl...@google.com <jl...@google.com> #3
Project: platform/frameworks/support
Branch: androidx-main
commit e782987543a9f8ccd485e970ddc74564b24378db
Author: Vighnesh Raut <vighnesh.raut13@gmail.com>
Date: Mon Jan 02 15:27:40 2023
fix: tab row crashes when only 1 tab is added
Bug: b/264018028
Test: Added unit test
Change-Id: I6381dbac304fc1d69d3708c6655f8b595668e93f
M tv/tv-material/src/androidTest/java/androidx/tv/material/TabRowTest.kt
M tv/tv-material/src/main/java/androidx/tv/material/TabRow.kt
https://android-review.googlesource.com/2373449
Branch: androidx-main
commit e782987543a9f8ccd485e970ddc74564b24378db
Author: Vighnesh Raut <vighnesh.raut13@gmail.com>
Date: Mon Jan 02 15:27:40 2023
fix: tab row crashes when only 1 tab is added
Bug:
Test: Added unit test
Change-Id: I6381dbac304fc1d69d3708c6655f8b595668e93f
M tv/tv-material/src/androidTest/java/androidx/tv/material/TabRowTest.kt
M tv/tv-material/src/main/java/androidx/tv/material/TabRow.kt
ch...@google.com <ch...@google.com> #4
deleted
jl...@google.com <jl...@google.com> #5
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.tv:tv-material:1.0.0-alpha04
jl...@google.com <jl...@google.com> #6
Hi Chuck,
Now the question is: how do I determine which NodeGroup to get the modifierInfo from.
Here is a dump of part of the SlotTable. The top node is a Text node that in the source code has a border modifier (BorderModifier).
However the NodeGroup with the modifierInfo does not appear before much later in the tree (underneath "Text", "CoreText", "Layout", "Layout" - and a bunch of other call nodes).
How do I determine that the modifier parameter of the Text node is actually the modifiers found much later ?
CallGroup("Text") - with a "modifier" parameter
- CallGroup(null)
- CallGroup("remember")
- CallGroup("Text")
- CallGroup(null)
- CallGroup(null)
- CallGroup("remember")
- CallGroup("CoreText")
- CallGroup("Layout")
- CallGroup("remember")
- CallGroup(null)
- CallGroup("Layout")
- CallGroup("Layout")
- CallGroup(null)
- CallGroup(null)
- CallGroup("remember")
- CallGroup(null)
- CallGroup("remember")
- CallGroup(null)
- CallGroup("remember")
- CallGroup("emit")
- NodeGroup (this NodeGroup has the BorderModifier). <----------------------------- Here is the BorderModifier that was a parameter for the first Text group node
- CallGroup(null)
- CallGroup("onCommit")
- CallGroup("remember")
Now the question is: how do I determine which NodeGroup to get the modifierInfo from.
Here is a dump of part of the SlotTable. The top node is a Text node that in the source code has a border modifier (BorderModifier).
However the NodeGroup with the modifierInfo does not appear before much later in the tree (underneath "Text", "CoreText", "Layout", "Layout" - and a bunch of other call nodes).
How do I determine that the modifier parameter of the Text node is actually the modifiers found much later ?
CallGroup("Text") - with a "modifier" parameter
- CallGroup(null)
- CallGroup("remember")
- CallGroup("Text")
- CallGroup(null)
- CallGroup(null)
- CallGroup("remember")
- CallGroup("CoreText")
- CallGroup("Layout")
- CallGroup("remember")
- CallGroup(null)
- CallGroup("Layout")
- CallGroup("Layout")
- CallGroup(null)
- CallGroup(null)
- CallGroup("remember")
- CallGroup(null)
- CallGroup("remember")
- CallGroup(null)
- CallGroup("remember")
- CallGroup("emit")
- NodeGroup (this NodeGroup has the BorderModifier). <----------------------------- Here is the BorderModifier that was a parameter for the first Text group node
- CallGroup(null)
- CallGroup("onCommit")
- CallGroup("remember")
ch...@google.com <ch...@google.com> #7
That I am not clear about since it depends on the implementation. There is no requirement that it even be used by it is highly likely to be.
However, it should always be the first NodeGroup
in the call group as anything else means the implementation is probably wrong.
jl...@google.com <jl...@google.com> #8
Hi George,
Now that a modifier can be based the "composed{}" construct, the Layout Inspector has trouble displaying these modifier parameters.
An example here is:
Text(Modifier.border(width = 10.0.dp, color = Color.Black)
The parameter value seen on the CallGroup for the Text node is a "ComposedModifier" i.e. the un-materialized modifier.
Obviously the system must have calculated the materialized version somewhere.
And in fact as seen in #6 the materialized border is found in a NodeGroup under a child node 4 levels deep: Text -> Text -> CoreText -> Layout -> Layout
It would be nice we could determine that the "ComposedModifier" found for the top level Text is in fact the "BorderModifier" seen in NodeGroup.
But I fail to see how I can make that association.
Do you see a way?
Now that a modifier can be based the "composed{}" construct, the Layout Inspector has trouble displaying these modifier parameters.
An example here is:
Text(Modifier.border(width = 10.0.dp, color = Color.Black)
The parameter value seen on the CallGroup for the Text node is a "ComposedModifier" i.e. the un-materialized modifier.
Obviously the system must have calculated the materialized version somewhere.
And in fact as seen in #6 the materialized border is found in a NodeGroup under a child node 4 levels deep: Text -> Text -> CoreText -> Layout -> Layout
It would be nice we could determine that the "ComposedModifier" found for the top level Text is in fact the "BorderModifier" seen in NodeGroup.
But I fail to see how I can make that association.
Do you see a way?
mo...@google.com <mo...@google.com> #9
I think I should be able to give access to the uncomposaed modifier so that you can access its information.
jl...@google.com <jl...@google.com> #10
That would be great.
Thank you.
Thank you.
ap...@google.com <ap...@google.com> #11
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 4faed1d7c573e5b475f549f159bbfe41278d47cd
Author: Jens Ole Lauridsen <jlauridsen@google.com>
Date: Wed Oct 07 15:01:31 2020
Add inspector info DSL to the composed modifier
This would allow the layout inspector to display information for
the unmaterialized modifiers found in the Compose parameters.
In this change: apply this for border modifiers.
Fixes: 163494569
Test: Unit test reenabled
Relnote: Add ability to specify inspector info in composed modifier
Change-Id: Idee08841816fb7dfc8f0621eb5a32c3663131aa1
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/Border.kt
M compose/ui/ui/api/current.txt
M compose/ui/ui/api/public_plus_experimental_current.txt
M compose/ui/ui/api/restricted_current.txt
A compose/ui/ui/samples/src/main/java/androidx/compose/ui/samples/InspectorInfoInComposedModifierSamples.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/ComposedModifier.kt
M ui/ui-tooling/src/androidTest/java/androidx/ui/tooling/inspector/ParameterFactoryTest.kt
https://android-review.googlesource.com/1447175
Branch: androidx-master-dev
commit 4faed1d7c573e5b475f549f159bbfe41278d47cd
Author: Jens Ole Lauridsen <jlauridsen@google.com>
Date: Wed Oct 07 15:01:31 2020
Add inspector info DSL to the composed modifier
This would allow the layout inspector to display information for
the unmaterialized modifiers found in the Compose parameters.
In this change: apply this for border modifiers.
Fixes: 163494569
Test: Unit test reenabled
Relnote: Add ability to specify inspector info in composed modifier
Change-Id: Idee08841816fb7dfc8f0621eb5a32c3663131aa1
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/Border.kt
M compose/ui/ui/api/current.txt
M compose/ui/ui/api/public_plus_experimental_current.txt
M compose/ui/ui/api/restricted_current.txt
A compose/ui/ui/samples/src/main/java/androidx/compose/ui/samples/InspectorInfoInComposedModifierSamples.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/ComposedModifier.kt
M ui/ui-tooling/src/androidTest/java/androidx/ui/tooling/inspector/ParameterFactoryTest.kt
Description
We want to be able to expect modifiers that are based on the
composed{}
construct and it's not possible right now because we need to have composition scope to be able to materialize them.For example,
Modifier.border
is based oncomposed{}
and we're not able to currently inspect its parameters.