rerun-io / rerun

Visualize streams of multimodal data. Free, fast, easy to use, and simple to integrate. Built in Rust.
https://rerun.io/
Apache License 2.0
6.68k stars 337 forks source link

Make the nodes draggable in the view #7916

Open abey79 opened 4 weeks ago

abey79 commented 4 weeks ago

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:

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).

teh-cmc commented 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?

abey79 commented 4 weeks ago

(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.)