Bind Node::force_parent_owned() as make_owned_by_parent() and bind Node::is_owned_by_parent() as is_managed_by_parent().

[Daylily-Zeleen]

Close proposal #9282.

[Daylily-Zeleen]

I decide to bind a new property owned_by_parent to decide a node is an internal node of parent or not and can be changed later by users, instead of exposing force_parent_owned() which can set it to true only.

[AThousandShips]

I see no valid reason to be able to clear this value, and it creates a huge risk for unintended errors IMO

[Daylily-Zeleen]

I see no valid reason to be able to clear this value, and it creates a huge risk for unintended errors IMO

Like my comment in #9282.
This change dose not change any existing logic, user who user this new feature should take responsibility for themselves (like EditorScript may lead to crash). So I don't think this change will bring any risk.

If I neglect something, please tell me, I will add a new field (may be named "owned_by_parent_override") to handle this feature.

[AThousandShips]

This change dose not change any existing logic

It does, you can't clear this, only set it

Sure you can break things in ways, but I don't think we should add features that make it easier

What's the use case for clearing this value? The setting the value is reasonable, but there's no reason I can see to clear it

[Daylily-Zeleen]

What's the use case for clearing this value? The setting the value is reasonable, but there's no reason I can see to clear it

A little confused, is the "clearing this value" you mentioned equal to data.parent_owned = false?

[AThousandShips]

Yes, that's what I mean :) there's no way to set it to false currently, because it's not needed, or safe

[Daylily-Zeleen]

Maybe a internal node which need processed, and take it out as a regular node at some situation (maybe extract a internal node and make it to be a regular node by a tool button).
This example is not very convincing, purely as a possibility, but it ultimately depends on the plugin developer.

Like ScrollContainer, if user clear ScrollBar's data.parent_owned, although this is strange, we cannot assume that it is wrong. In other words, we cannot assume the behavior of developers.

To be honest, I didn't think much about clearing this value. I just want it to become an property for convenience (both get and set).

[AThousandShips]

Let's keep it as a method and not a property, there's no reason to clear it, and it is wrong in my opinion, there's no reason to ever clear it, it's not a matter of assuming, it's a matter of what this property is for and what it makes sense for

If you want to clear it all you need to do is reparent it

[AThousandShips]

I'm not sure this is necessary to mention

[AThousandShips]

Suggested change

	[b]Note:[/b] You can reparent a managed node to make it become a regular node.
	[b]Note:[/b] Reparenting this node resets the managed status.

If we need to keep it

On a second though there might be a better solution. See my comment in the proposal.