[3.x] Backport CanvasLayer visibility

[timothyqiu]

• Backports Minor code improvement in CanvasItem (show/hide/set_visible) #56734.
  • It moves show() and hide() logic into set_visible(), so later changes are easier.
• Backports Add visibility to CanvasLayer #48006.
  • The original PR that adds visible property and visibility_changed signal to CanvasLayer.
• Backports Rework CanvasItem visibility propagation #57684.
  • It fixes a bug in CanvasLayer visiblity propagation of the original PR.
  • It fixes hidden signal so that it won't be emitted again when the CanvasItem was already invisible.
  • is_visible_in_tree() is now as cheap as is_visible()

[lawnjelly]

Why is the new variable called visible_in_tree, if it is not whether the item is visible in the tree? Should this be parent_visible_in_tree?

[KoBeWi]

In 4.0 it can depend on Window, which might not be a direct parent.

[lawnjelly]

Could there be a better name for this? It strikes me as confusing.

In a sense with a window too, it is still the parent. Because the window is similar to a parent, and if the window isn't a direct parent, then the effects of the window are mediated by the direct parent?

At least that seems better than calling it something which it isn't, which is the case at the moment.

Essentially if I'm understanding correctly the logic is:

IF MY PARENT IS VISIBLE IN THE TREE and I'M VISIBLE then I'M VISIBLE IN THE TREE

[timothyqiu]

Does ancestors_visible_in_tree make sense?

[lawnjelly]

It's much better than is_visible_in_tree yes. Personally I think to stretch to using parent is fine here too, but we can see what others think. 👍

[timothyqiu]

FYI, the classref uses antecedents.

if the node is present in the SceneTree, its visible property is true and all its antecedents are also visible

[lawnjelly]

I'm not sure about antecedent - it is not really a commonly used English word, and most people would have to look it up to find the definition (including me as a native speaker 😀 ).

You could also use parent_and_window_visible_in_tree potentially if worried about the window thing (not so relevant in 3.x but no problem having this carryover). Ancestors is fine too, to me it's a bit overkill because if your parent is visible in the tree, then by definition the ancestors are also visible.

But yeah ancestors is fine if you are struggling and don't want to use parent.

They do say naming things is one of the most difficult problems in computer science lol.

[akien-mga]

Either way, changing is_visible_in_tree() would break compatibility in 3.x.

[KoBeWi]

The discussion is about variable name, which is the same as the method name, but does different thing.

[akien-mga]

Then parent_visible_in_tree is what it tracks I think? There's no Window visibility involved in 3.x.

[akien-mga]

Thanks!