Open abey79 opened 4 weeks ago
A correct implementation should transcribe the drag-and-drop interaction in the view into
Position2D
component overrides. However, for this to happen, we need per-instance override semantics.
(I'm not familiar with the data model behind the new graph stuff)
Why do we need per-instance overrides at all? I.e. why is overriding all the positions in the position batch everytime any node is moved around not an option?
(I'm not familiar with the data model behind the new graph stuff)
Consider the GraphNode
archetype has an optional Position2D
component. Fallback to some kind of auto-layout (which could initially be as stupid as "arrange all nodes on a circle"). We can ignore edges here.
Why do we need per-instance overrides at all?
I think this is required for the cases where the user logged time-varying Position2D
. When one node is moved around in the UI, it's now-overridden position should apply regardless of the position of the time cursor, and should only affect that particular node. For that to happen, the un-overridden instance should be left "empty" in the override, because there is no "previous value" to duplicate (the previous value being time-varying).
(With that said, I now realise that there is an alternative approach that's hacky w.r.t to rerun data model, but closer to the graph view semantics we already decided. I'm adding it to the list.)
Manually dragging the nodes in the graph view is useful both for fine-tuning the presentation and to interact with the (future) auto-layout algorithm for analysis purposes.
A correct implementation should transcribe the drag-and-drop interaction in the view into
Position2D
component overrides. However, for this to happen, we need per-instance override semantics.Possible solutions:
ManuallySet: [bool]
component, to track which instances of thePosition2D
instances should be considered. Insanely hacky, but doable without changing our data model.Position2D
. One would be tagged withmanually_set
. In the future, another one could bedynamic_auto_layout
, to store the intermediate states of the force-based auto-layout, should we want to expose them to the user across several frames.ManualNodePositions: { node_id: Utf8, position: Vec2D }
view property (not override) might be a better fit to theGraphView
, because the overridden position would be related to a give node id, which is much more stable than a node instance index (a given node id might be logged under different instance index at different point in time). This would allow us to entirely side-step the "per-instance-override" question entirely.Another aspect of this is how poor the current override UI is with non-mono-component (although in this case this is not a limiting factor strictly speaking, as the instance edit would happen via in-view UI interaction).