Solve the reversed-dependency logic in Object parenting. #107949

New Issue

Bastien Montagne · 2023-05-15T20:15:30+02:00

Bastien Montagne commented

2023-05-15 20:15:30 +02:00

Current relationship between an object and its child at data-block level is reversed compared to the user-level one: the child points to its parent, which means that at ID management level the child is the 'owner' of its parent.

This is fully reversed compared to (expected) user understanding, where the child should be a dependency of its parent. This is illustrated e.g. in the Outliner tree view, where the child is shown as part of its parent hierarchy.

This reversed order of dependency between the user-level and data-level representations has always been a source of issues (e.g. complex weird code in Outliner tree building code, weird behavior in ID linking, e.g. when linking a parent object, it would not automatically link its children, and more recently more complex code in liboverride hierarchies handling).

The proposal to address this issue is to add a list of children objects to the parent one. Most likely implemented in a similar way as with e.g. collections children (i.e. a listbase of wrapper struct around object pointers). These new relationships would be come the 'main' ones between parents and children.

The current 'parent' pointer would be kept, but would become a 'loopback' pointer from ID management perspective (similar e.g. to the 'from' pointer of embedded IDs and shapekeys, or the 'parent' pointers of a collection).

That way, only the code setting a parent needs to be updated (and some versioning to initialize the list of children of course), and there should be no forward or backward compatibility breakage at all, since the existing parent pointer remain in use and keep the same meaning.

The only unknown consequences may come from moving that 'parent' pointer into the 'loopback' category in the lib_query foreach_id processing. It will certainly fix issues (or make existing code simpler by removing needs for special case handling), but it may also cause unexpected changes.

Current relationship between an object and its child at data-block level is reversed compared to the user-level one: the child points to its parent, which means that at ID management level the child is the 'owner' of its parent. This is fully reversed compared to (expected) user understanding, where the child should be a dependency of its parent. This is illustrated e.g. in the Outliner tree view, where the child is shown as part of its parent hierarchy. This reversed order of dependency between the user-level and data-level representations has always been a source of issues (e.g. complex weird code in Outliner tree building code, weird behavior in ID linking, e.g. when linking a parent object, it would not automatically link its children, and more recently more complex code in liboverride hierarchies handling). The proposal to address this issue is to add a list of children objects to the parent one. Most likely implemented in a similar way as with e.g. collections children (i.e. a listbase of wrapper struct around object pointers). These new relationships would be come the 'main' ones between parents and children. The current 'parent' pointer would be kept, but would become a 'loopback' pointer from ID management perspective (similar e.g. to the 'from' pointer of embedded IDs and shapekeys, or the 'parent' pointers of a collection). That way, only the code setting a parent needs to be updated (and some versioning to initialize the list of children of course), and there should be no forward or backward compatibility breakage at all, since the existing parent pointer remain in use and keep the same meaning. The only unknown consequences may come from moving that 'parent' pointer into the 'loopback' category in the `lib_query` foreach_id processing. It will certainly fix issues (or make existing code simpler by removing needs for special case handling), but it may also cause unexpected changes.

Bastien Montagne added the

labels 2023-05-15 20:15:30 +02:00

Bastien Montagne added this to the Core project 2023-05-15 20:15:32 +02:00

Sign in to join this conversation.