Open goderbauer opened 6 years ago
@jacob314
While we are adding more trees, would seeing the Layer tree also be useful? Showing these trees will be cheap as they are already ported to use DiagnosticsNode on the Flutter side.
I have never used the Layer tree for debugging, so I'll defer to @Hixie to answer that question.
Layer tree isn't going to be that helpful to a lot of people, but certainly it will be helpful to some. Much like the accessibility tree.
What do you think of having the Semantics and Layer tabs only show up in the inspector if a menu item in the "Additional Actions" in the Flutter Inspector view has been checked? Here are the options on the menu currently:
Is the Semantics tree something app developers would use? If it's more for framework engineers or someone who has special needs of app accessibility, let's hide it in the menu.
The semantics tree is something you would use when making your app accessible. The layer tree is something you would use when debugging a compositing problem with your app.
In practice there is little difference between a "framework engineer" and an "app developer" once the app developer is advanced enough.
I agree there is no hard distinction between framework engineers and app developers. I'd like to learn more about the kinds of issues these two trees can help diagnose.
Does a compositing problem usually indicate a bug in the framework or engine, or can it be caused by incorrect use of Flutter APIs?
The Semantics Tree is also useful for app developers that want to make their app accessible. I just used it to figure out why a certain text widget in an app is not focusable. And the Semantics Tree showed me that that text actually got merged into another semantics node.
Does a compositing problem usually indicate a bug in the framework or engine, or can it be caused by incorrect use of Flutter APIs?
There's very little distinction between "framework" code and code that makes "use of Flutter APIs". We expect developers to create their own Layer subclasses, their own RenderObjects, their own Widgets, etc.
You would need the layer tree (or rather, be helped by the layer tree) if you were to try and debug performance issues, logic issues with custom layers, that kind of thing.
+1 for customer:mulligan
+1 on the layer tree. Large enterprise users would definitely appreciate being able to visualize the layer tree in non-ascii form.
Seeing the Widget and Render Tree Hierarchy in the Flutter Inspector is great. Would love to also see the Semantics Tree there.