class LayoutHost

Committed layout from the last calculateLayout (hit-test / queries read this).

Frames from the most recent layout, for frames that only redraw.

Generations of setRoot — for tests / dumps.

Find nodes by substring match on sid/label/text. Returns flat list of {sid,id,label,type,text?,x,y,w,h,interactive} (max limit).

Frame of the first node whose label equals label (committed layout).

Frame by process-local NodeID (not stable across launches).

Frame by stable agent id or structural path (sid from layout_tree).

Topmost layout label under a point (debug helper for agents).

Nested layout tree suitable for JSONSerialization.

JSON string of agentLayoutTree.

Layout into a definite viewport size (window / body pixels).

The root Yoga node is given an exact width/height matching the viewport. With width: auto alone, Yoga sizes the root to its content and flexGrow children never receive free space — so after a window resize the UI stayed content-sized (black empty region). Setting definite root dimensions is the standard full-window Yoga pattern.

Diagram host from committed layout — does not re-run Yoga.

Dismisses everything presented. Returns true if anything was showing, so a key handler can tell whether it consumed the event.

The nearest .onDragGesture at this point, walking outwards.

The nearest .onDrop handler at this point, innermost first.

Not hitTestHover, which resolves exactly one node and is right for a highlight and wrong for a drop: the topmost thing under the pointer is almost never the view that registered the handler. In LavaView it is the picture, in an editor the text — and a child with no interest in drops must not swallow the one its parent is waiting for. So the chain is walked outwards and the first handler along it wins, which is what every other drag-and-drop implementation means by "the drop target".

The nearest .onFileDrag source at this point, found the way dropTarget finds a drop target and for the same reason: the press lands on a row's label, and it is the row that registered.

Reverse-z hit test against committed Yoga geometry (no re-layout). originY matches emit offset (menu bar). Window-pixel coordinates.

Topmost interactive node under the pointer, for hover highlighting.

What the renderer would call hovered at this point.

Deliberately not hitTestHover. That one answers a local question — which node should highlight, which container a wheel notch belongs to, what a file was dropped on — and it counts scrollables and drop targets as hover targets because those are the things it exists to find. The renderer counts something narrower: the nodes it was handed a hit-test flag for, which is isRendererInteractive and nothing else.

The distinction matters exactly once, and it is enough: an injected pointer in a client has no renderer to answer .nodeHover, so this is what stands in for it, and it has to give the same answer the renderer would or a Button will not believe the pointer is on it.

Deepest wins, matching RenderWindow::updateSceneHover, which walks a pre-order list and keeps the last node containing the point.

Every node under the pointer that a wheel event may be offered to, innermost first.

Hover resolves exactly one node, which is right for highlighting and wrong for the wheel: a button, text field, or canvas sitting inside a ScrollView is the topmost hit, so routing by hover alone let it mask the container and a notch over it scrolled nothing. This keeps the whole ancestor path instead so ScrollRouter can bubble. Deliberately a separate walk — hover and click targeting stay exactly as they were.

After FontStore content-scale change: force every text leaf to re-measure on the next calculateLayout (library helper).

Every .onAnyPress containing this point, innermost first.