Repository navigation
Conversation
…#3489) * Add a method for finding a path from currently selected row item to the tree root (flutter#3489) * Add InspectorBreadcrumbNavigator (flutter#3489) * Set text style explicitly (flutter#3489) * Notify controller about selected widget on tap (flutter#3489) * Make currently selected item not clickable (flutter#3489) * Move breadcrumbs out of scrollable tree container (flutter#3489) * Tweak padding size and appearance parameters (flutter#3489) * Scroll to the end of the list so the last breadcrumb is always visible (flutter#3489) * Simplify constructor (flutter#3489) * Provide inspector tree controller directly to the tree widget where needed (flutter#3489) * Provide dummy inspectorTreeController to tests in inspector_tree_test (flutter#3489) * Ensure inspectorTreeController is provided when InspectorTree is showing a widget detail tree (flutter#3489) * Test if breadcrumbs widget is displayed (flutter#3489) * Remove empty constructor (flutter#3489) * Use row for showing breadcrumbs (flutter#3489)
Disable Details tree search & Highlight search matches with orange color & breadcrumbs
…instance_viewer_test.dart (flutter#3489)
|
Now that #3525 is merged, can you merge master or rebase so that this change is easier to review? thank you |
# Conflicts: # packages/devtools_app/lib/src/inspector/diagnostics.dart # packages/devtools_app/lib/src/inspector/inspector_screen.dart # packages/devtools_app/lib/src/inspector/inspector_tree.dart # packages/devtools_app/lib/src/inspector/inspector_tree_controller.dart # packages/devtools_app/lib/src/ui/search.dart
|
Done. Please review it as a prototype for evaluating performance rather than a production ready changes. I'd like to know if it makes any sense to continue working on this. I'm personally not very happy with the performance at the moment. I'd want to explore a possible improvement - showing matches as soon as they're found without waiting for search to complete |
|
Overall, I think the performance is okay. If we can speed up the search at all, even better. I tested this patch out on a large internal app, and with the search scope "All" and a one-letter search query, the search was completing in ~5-6 seconds. The search spinner notifies the user that something is happening, so the UI doesn't feel stalled. If we want, we could warn the user that when they select the "details" or "all" scope, searches may take a bit longer than if the "widget" scope is selected. @InMatrix thoughts? @aednlaxer - Is the worst case search time I was seeing comparable to what you experienced when working on this feature? Is there another way I should be testing the worst case other than with a large app and a one letter search query? A couple other comments:
|
|
One more comment. It appears in the current state that only the properties are coming up as matches when the search scope is Details or All. Here's an example where the search query is "in" but only properties in the details tree are highlighted, even though there are widgets in the details tree that also contain the "in" string in their name. This seems like a bug and that we would want to include both widgets and properties in search matches within the details / all scopes. |
|
@kenzieschmoll thank you for your comments. Sorry, I didn't have time to focus on this recently but I'd like to work on improving this soon. I was connecting to devtools itself to experiment with properties search and was getting similar performance results. |
|
@aednlaxer is this still something you are interested in working on? |
|
This is not something I've been actively developing recently, I believe this should be closed |
This pull request is based on #3525 and adds search of widget properties and property values. I'd like to ask you to evaluate the performance of details search and to give your opinion on that (maybe as a comment to ticket #3489). This PR is not ready for review although all comments are welcome.
Details search can be enabled by choosing 'All' or 'Details' in the search box dropdown:
There's room for improvement. Some ideas how to make user experience better:
searchPreviousMatches(commented out for now)intcomponents so they're not found when search query is a hex codeDataSearchStateMixinso the total number of search matches doesn't include the number of matching properties. Previous\next buttons don't navigate among these matches for the same reason.