Fixed
Status Update
No update yet.
Comments
ch...@google.com
Unless I am missing something, it looks like the modifiers collected by the tools API are the materialized versions. The un-materialized versions are available as data in the slot tree but Group reports the materialized modifiers in the modifierInfo list.
jl...@google.com
According to this inspection in the debugger, it looks like the modifier parameter is the un-materialized version.
This is a parameter from a Text node where I specified:
modifier = Modifier.border(width = 10.0.dp, color = Color.Blue)
This is a parameter from a Text node where I specified:
modifier = Modifier.border(width = 10.0.dp, color = Color.Blue)
ch...@google.com
That is certainly true. The modifiers passed in as parameters are unmaterialized but you should be able to find the materialized version in the corresponding node group.
jl...@google.com
Oh, OK. Thanks.
Let me try that.
Let me try that.
jl...@google.com
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
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
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
I think I should be able to give access to the uncomposaed modifier so that you can access its information.
jl...@google.com
That would be great.
Thank you.
Thank you.
ap...@google.com
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.borderis based oncomposed{}and we're not able to currently inspect its parameters.