read method

InspectTree read({ InspectFilter? filter, })

The tree as of the last build.

Always the summary tree — the widgets the framework attributes to the user's code. There is deliberately no "give me everything" here, and the reason is worth recording because it looks like an omission: of the two public in-process readers, WidgetInspectorService.getRootWidgetSummaryTree returns a whole tree and getRootWidget returns the root and one level. The unfiltered whole tree is reachable only through the service extension, over a socket, from another process.

So a full option here could only have been a filter over an already-filtered list — which is to say, a parameter that reads as a capability and does nothing. It was written that way first and measured: 44 nodes either way, zero of them non-local. If the whole tree is ever wanted it is a host-side call and its own decision.

filter narrows what comes back and nothing else — the walk is the same walk, because the ids have to keep meaning positions in the whole tree. Unfiltered by default, which is what the inspect panel and the previews client have always been handed; the drive loop is the caller that asks for less.

Implementation

InspectTree read({InspectFilter? filter}) {
  var tree = _build().tree;
  return filter == null ? tree : tree.filtered(filter);
}