Activity

1. InMatrix

   added

   usability

   on Apr 12, 2021
2. InMatrix commented on Apr 12, 2021

   

   InMatrix

   on Apr 12, 2021

   More actions

   Thank you so much for filing this issue! I'm impressed by how comprehensive and organized it is. Please see my initial comments on the problems you noted inline below. Hope these help us start a discussion and identify a starter project for our collaboration. Cc: @jacob314 @kenzieschmoll @csells @devoncarew

   The team interviewed our own Flutter developers for deeper insights and to gain a broader understanding of how developers actually use the tools in their day-to-day work.

   I really appreciate that you did this. It's advantageous that you could combine your design capability and experience using Flutter.

   Currently the widget tree is hard to visually scan through and developers find it hard to locate widgets within the tree.

   Agreed. I think we can do a better job distinguishing different families of widgets based on the functionalities they provide (e.g., layout, decorative, information container, animation, etc). The Widget catalog provides a starting point for such a taxonomy.

   Another idea we could explore is to match the visual salience of a widget in the tree with its size on the screen. For example, if there are two Text widgets, one for a small label and another for a paragraph of text. The two widgets should ideally be represented differently in the widget tree in a way that the developer can tell which one is which at a glance. The necessary sizing data might be already available from the widgets' corresponding renderObjects.

   Matching the colors of the layout explorer and details tree with the opened widget in the widget tree

   I can see the mismatch now you mentioned that. Some tweaks of the colors could be useful.

   The most common feedback from our developers regarding the Layout Explorer is that it’s too busy and cluttered with data.

   Yes, agreed. I'd be interested in any ideas to convert text into visual representations or disclose certain options progressively. We might also consider converting some menu-based operations into direct manipulation on the layout diagram.

   It’s unclear which elements within the Layout Explorer are clickable, and which are just labels.

   +1. This seems relatively easy to fix.

   We feel the vertically rotated labels are difficult to read, requiring the user to tilt their head.

   I'd be interested in seeing some examples of UIs that handle this problem well. Would you share some pointers or preliminary thoughts?

   Currently the layout explorer has a lot of the data duplication.

   Could you elaborate on the data duplication you were seeing?

   There's a slight delay when clicking boxes/dropdowns in the Layout Explorer.

   This might be due to the fact that an actual hot reload needs to be performed to reflect the change. Maybe a progress indicator can be added to let the user know what's going on before the diagram is refreshed. Cc: @jacob314

   Details Tree

   I agree with the suggestions. However, our current thinking is to move the most frequently used information from the Details Tree to Layout Explorer and represent it as visually as possible. In the future, the Details Tree might be reserved for debugging edge cases or advanced users. So I'd wait until we've made more progress on the Layout Explorer.

   Buttons and icons for debug toggles

   Yes, tooltips or click feedback needs to be provided to better explain what these buttons do. The information is available on this page: https://flutter.dev/docs/development/tools/devtools/inspector. We could also explore an onboarding flow to introduce the features in the inspector page.

   Explore trying out different values in the details tree

   This is something we want to do in the long run, but it's likely to require a lot of engineering effort to make it work well. So it's probably not a good candidate for our starter project here.

   Contain the action within the context of their use to make the top area of the DevTools a bit more structured.

   I'd love to hear more about this suggestion. Could you point out an action that you'd like to relocate?

   Improve color contrast
   Accessibility

   Yes to both. I think we have technical debt on accessibility, and improving color contrast would be the first step to address it. Fully supporting VoiceOver might be more challenging, we'd love to learn similar tools such as Chrome DevTools have supported it.
3. InMatrix

   added

   polish

   on Apr 12, 2021
4. jacob314 commented on Apr 13, 2021

   

   jacob314

   on Apr 13, 2021

   Contributor

   More actions

   This might be due to the fact that an actual hot reload needs to be performed to reflect the change. Maybe a progress indicator can be added to let the user know what's going on before the diagram is refreshed. Cc: @jacob314

   Good news is we don't actually perform a hot reload for this case so we can make it much faster. We should profile where the operations to change flex properties are sluggish. It should be extremely fast as we are just changing properties on a render object and then triggering a layout and paint. I suspect we are doing something foolish on the DevTools side updating the UI after the property change.

   Here is the implementation is in inspector_polyfill_script.dart

   Future<Map<String, dynamic>> setFlexProperties(
         Map<String, String> parameters) {
       final String id = parameters['id'] as String;
       final MainAxisAlignment mainAxisAlignment = toEnumEntry<MainAxisAlignment>(
         MainAxisAlignment.values,
         parameters['mainAxisAlignment'] as String,
       );
       final CrossAxisAlignment crossAxisAlignment =
           toEnumEntry<CrossAxisAlignment>(
         CrossAxisAlignment.values,
         parameters['crossAxisAlignment'] as String,
       );
       final dynamic object = WidgetInspectorService.instance.toObject(id);
       bool succeed = false;
       if (object != null) {
         final render = object.renderObject;
         if (render is RenderFlex) {
           render.mainAxisAlignment = mainAxisAlignment;
           render.crossAxisAlignment = crossAxisAlignment;
           render.markNeedsLayout();
           render.markNeedsPaint();
           succeed = true;
         }
       }
       return Future.value(<String, Object>{'result': succeed});
     }
5. jacob314 commented on Apr 13, 2021

   

   jacob314

   on Apr 13, 2021

   Contributor

   More actions

   One other idea for the inspector tree is to highlight widgets defined in your local project (in this demo in blue) and then optionally only expand other widgets when the build method for the selected widget is selected. This makes the structure of the user's own app clearer from the summary tree and better matches the mental model of going one build method at a time from browsing source code.
   Here is a demo of what this could look like.

   inspector_tree_animation_video.mp4

   👍React with 👍1Reacted by CodemateTechAgency
6. CodemateTechAgency commented on Apr 16, 2021

   

   CodemateTechAgency

   on Apr 16, 2021

   Last edited by CodemateTechAgency

   Author

   More actions

   Currently the layout explorer has a lot of the data duplication.

   Could you elaborate on the data duplication you were seeing?

   Well, the word unconstrained is repeated many times. Not a problem per se, seeing it is important information, but now all that info is scattered around the box. So it is not just about duplication, but also about the space it takes.

   

   We feel the vertically rotated labels are difficult to read, requiring the user to tilt their head.

   I'd be interested in seeing some examples of UIs that handle this problem well. Would you share some pointers or preliminary thoughts?

   This comes back to the same point as above. It is not just about rotated labels/values, but about the amount of data presented there.

   Here’s an initial design idea for the Flutter Inspector:

   

   Contain the action within the context of their use to make the top area of the DevTools a bit more structured.

   I'd love to hear more about this suggestion. Could you point out an action that you'd like to relocate?

   With the current label of “Refresh Widget Tree”, I’d move that within the boundaries of the widget tree. If it basically refreshes everything, then it could be where it currently is, but maybe change the label then.

   For layout inspector / details tree, I’d contain the tab (and expand/collapse actions) within the boundaries to separate them visually from the upper button group

   Also, maybe move the “Select Widget Mode” button along the button group with the other actions affecting the live preview. Remove the grouping of the overlays (or include them all in a same toggle group).

   Improve color contrast
   Accessibility

   Yes to both. I think we have technical debt on accessibility, and improving color contrast would be the first step to address it. Fully supporting VoiceOver might be more challenging, we'd love to learn similar tools such as Chrome DevTools have supported it.

   Chrome DevTools does support VoiceOver, but not especially well. We agree it would be a huge challenge to support screen readers on the DevTools

   👍React with 👍2Reacted by Tao Dong and Jacob Richman
7. elliette

   added

   inspector-2.0-polishPolish work that can be tackled once Inspector 2.0 has landed.Polish work that can be tackled once Inspector 2.0 has landed.

   devtools-inspector-screen

   P2important to work on, but not at the top of the work list.important to work on, but not at the top of the work list.

   on Oct 3, 2024
8. elliette commented on Dec 2, 2025

   

   elliette

   on Dec 2, 2025

   Member

   More actions

   Closing this issue in favor of the sub-issues created above.

   Note that the widget tree issues have been addressed as part of the Inspector 2.0 work (which also removed the details tree) and trying out different widget values is now supported via the Property Editor .

   🚀React with 🚀1Reacted by Felipe Morschel
9. elliette

   closed this as completedon Dec 2, 2025