英文:
Column semantics read AFTER first element in column
问题
I'll provide the translation for the code section as requested:
// 这部分是代码，不需要翻译
val list = listOf("String 1", "String 2", "String 3")
Column(
Modifier.semantics { contentDescription = "test" }
) {
list.forEach {
Text(it)
}
}
英文:
Yet another weird case of semantics in Jetpack Compose....
val list = listOf("String 1", "String 2", "String 3")
Column(
Modifier.semantics { contentDescription = "test" }
) {
list.forEach {
Text(it)
}
}
If you use this code and then use TalkBack for some reason the first Text will be highlighted and then when you swipe the Column will highlight and then swipe once more and you'll be taken to the second label. After that it acts normal. I'm thinking something in the semantic hierarchy of the version of compose I'm on is completely messed up. But I don't know how to prove it. LayoutInspector shows everything as it should as as I expect it would. But something is not translating.
Is anyone aware of this? I am not sure where to report these semantics issues or research their problems. I'm still learning some compose aspects.
答案1
得分: 0
尝试移除 Modifier.semantics { contentDescription = "test" }
示例：
val list = listOf("String 1", "String 2", "String 3")
Column {
list.forEachIndexed{ _, value ->
Text(text = it, modifier = Modifier.semantics { contentDescription = value })
}
}
英文:
Try remove Modifier.semantics { contentDescription = "test" }
Example:
val list = listOf("String 1", "String 2", "String 3")
Column {
list.forEachIndexed{ _, value ->
Text(text = it, modifier = Modifier.semantics { contentDescription = value })
}
}
答案2
得分: 0
So I found out a lot of information today. I misunderstood my own problem at first and realized I needed to validate previous versions. In this question I was using 1.4.0 of compose. In this case, foundation and compose-ui.
As it turns out 1.4.0 is when this issue was introduced.
I have begun tracking this issue with the Open Source Project here. The gist of the issue seems to fall into a bug fix for UI, but oddly enough foundation causes the same issue. I've yet to determine the cause of that issue.
Using compose-ui#1.3.3 and foundation#1.3.1 does remedy this. Which is not ideal. I do not currently have a solution better to this. If you're wanting some of the functionality of 1.4.0; 1.4.0-beta01 is the latest version that does not have this issue for both UI and Foundation. Moving to 1.4.0-beta02 of either will introduce the issue.
Future of this issue: There seems to be a semantic parameter added to compose-ui#1.4.0 called isContainer. This may be the resolution they are already working on moving forward, but we do not have any details on the effort at this time.
英文:
So I found out a lot of information today. I misunderstood my own problem at first and realized I needed to validate previous versions. In this question I was using 1.4.0 of compose. In this case, foundation and compose-ui.
As it turns out 1.4.0 is when this issue was introduced.
I have begun tracking this issue with the Open Source Project here. The gist of the issue seems to fall into a bug fix for UI, but oddly enough foundation causes the same issue. I've yet to determine the cause of that issue.
Using compose-ui#1.3.3 and foundation#1.3.1 does remedy this. Which is not ideal. I do not currently have a solution better to this. If you're wanting some of the functionality of 1.4.0; 1.4.0-beta01 is the latest version that does not have this issue for both UI and Foundation. Moving to 1.4.0-beta02 of either will introduce the issue.
Future of this issue::
There seems to be a semantic parameter added to compose-ui#1.4.0 called isContainer. This may be the resolution they are already working on moving forward, but we do not have any details on the effort at this time.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论