You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The collision detector is currently limited to detecting collisions with Sibling nodes. When using a hierarchic layout, the collision detector will provide many false-positive collisions. For example, it isn't possible to move a node inside of its parent, because child nodes always conflict with the bounds of their parent.
There is also an issue when using a shape for e.g. compartments: shrinking a node will cause a collision between the Compartment figure and its parent Node (Even though the Compartment is logically a part of the node).
In some cases, it may be tricky to distinguish the elements that should be taken into account and the ones that should be ignored (For example, child nodes that have a fixed size should be considered for collision-testing, but child nodes that can be dynamically resized - such as compartments or wrappable/truncatable labels - may be ignored)
The text was updated successfully, but these errors were encountered:
@planger Is this something that we should fix for the 1.0.0 release? Or are you fine with the fact that the MovmentRestrictor API can currently no be used in combination with client-side layouting?
As far as I understand, the movement restrictor cannot be used for hierarchical nodes, right? It still works with client-side layouting in general, right?
If yes, I'd be ok with that. I think the combination of both hierarchical nodes and movement restriction is something quite specific that typically requires customization anyway.
The collision detector is currently limited to detecting collisions with Sibling nodes. When using a hierarchic layout, the collision detector will provide many false-positive collisions. For example, it isn't possible to move a node inside of its parent, because child nodes always conflict with the bounds of their parent.
There is also an issue when using a shape for e.g. compartments: shrinking a node will cause a collision between the Compartment figure and its parent Node (Even though the Compartment is logically a part of the node).
In some cases, it may be tricky to distinguish the elements that should be taken into account and the ones that should be ignored (For example, child nodes that have a fixed size should be considered for collision-testing, but child nodes that can be dynamically resized - such as compartments or wrappable/truncatable labels - may be ignored)
The text was updated successfully, but these errors were encountered: