NodeEditorRenderer draws a fixed node body and offers no way for a host to add content to it, so a widget inside a node is not reachable without abandoning the renderer. Raised while investigating #437.
What happens
RenderNode (NodeEditorRenderer.cs:305) submits a title bar, then one ImGui.Text per input pin and one right-aligned ImGui.Text per output pin, between ImNodes.BeginNode (:340) and ImNodes.EndNode (:396). There is no callback anywhere on the type: no property on NodeEditorRenderer is an Action or a Func.
ImNodes itself has no such restriction. Anything submitted between BeginNode and EndNode, or inside an attribute's begin and end pair, is drawn in the node and sized into it, which is how a slider or a combo ends up on a node in the usual ImNodes idiom.
Why it matters
A host wanting a value editable on the node face has two choices today, and both are bad. Fork the renderer, which means giving up zoom, hover highlighting, the measured position and dimension feedback and the pin offset publishing, all of which live in this class. Or draw the graph with raw ImNodes calls and use NodeEditorEngine for topology and physics alone, which throws away the same things.
A renderer hook is also the piece that makes the pin offsets keep working. The engine measures a link between the points a renderer joins, via UpdatePinOffset, and PublishPinOffsets runs off the rows this method records. Content drawn by a host inside the node changes those rows, and the renderer is the only place that can see the change.
Sketch
A per-node callback invoked inside the node, after the pins:
public Action<Node>? DrawNodeBody { get; set; }and possibly a per-pin one, invoked inside the input attribute so an unconnected input can offer an inline editor in the place the value would arrive:
public Action<Node, Pin>? DrawPinBody { get; set; }Both would need to say clearly what the host may and may not call: the id stack is the node's, the cursor is mid-node, and ImNodes sizes the node from whatever gets submitted.
The per-pin form is the one that matters for #437 and needs the most thought, because whether an input pin should show an editor depends on whether it is connected, which is a question about the graph and not about drawing.
Related
NodeEditorRendererdraws a fixed node body and offers no way for a host to add content to it, so a widget inside a node is not reachable without abandoning the renderer. Raised while investigating #437.What happens
RenderNode(NodeEditorRenderer.cs:305) submits a title bar, then oneImGui.Textper input pin and one right-alignedImGui.Textper output pin, betweenImNodes.BeginNode(:340) andImNodes.EndNode(:396). There is no callback anywhere on the type: no property onNodeEditorRendereris anActionor aFunc.ImNodes itself has no such restriction. Anything submitted between
BeginNodeandEndNode, or inside an attribute's begin and end pair, is drawn in the node and sized into it, which is how a slider or a combo ends up on a node in the usual ImNodes idiom.Why it matters
A host wanting a value editable on the node face has two choices today, and both are bad. Fork the renderer, which means giving up zoom, hover highlighting, the measured position and dimension feedback and the pin offset publishing, all of which live in this class. Or draw the graph with raw ImNodes calls and use
NodeEditorEnginefor topology and physics alone, which throws away the same things.A renderer hook is also the piece that makes the pin offsets keep working. The engine measures a link between the points a renderer joins, via
UpdatePinOffset, andPublishPinOffsetsruns off the rows this method records. Content drawn by a host inside the node changes those rows, and the renderer is the only place that can see the change.Sketch
A per-node callback invoked inside the node, after the pins:
and possibly a per-pin one, invoked inside the input attribute so an unconnected input can offer an inline editor in the place the value would arrive:
Both would need to say clearly what the host may and may not call: the id stack is the node's, the cursor is mid-node, and ImNodes sizes the node from whatever gets submitted.
The per-pin form is the one that matters for #437 and needs the most thought, because whether an input pin should show an editor depends on whether it is connected, which is a question about the graph and not about drawing.
Related