Clarify CanvasItem's visibility signal descriptions (followup)

[AdriaandeJongh]

Follow-up to: #97223 (comment)

Simplifies the signal descriptions of CanvasItem's hidden and visibility_changed. I tried a couple different ways of having the description for hidden refer to the visibility_changed description, but as hidden is just above it, it would read weird? idk.

It's curious that the hidden signal still exists even though the visibility_changed signal (albeit together with a simple check to is_visible_in_tree in the connected callable) essentially supersedes it, but I don't know any C++ to deprecate the signal and start a transition to remove it. Perhaps someone else could pick that up.

[Mickeon]

but as hidden is just above it, it would read weird?

Personally, you usually need to look at each description such that they can be understood individually. Unless, say, there's a whole lot of explaining to do that does not warrant repetition.
Imagine the description as if it's showing up as a tooltip.

[Mickeon]

I actually like the prior descriptions more, I feel out of the loop here. I do understand that top_level's existence makes the statement misleading, though.

[Mickeon]

It's curious that the hidden signal still exists even though the visibility_changed signal (albeit together with a simple check to is_visible_in_tree in the connected callable) essentially supersedes it, but I don't know any C++ to deprecate the signal and start a transition to remove

The hidden signal actually has a lot of applications internally, and I can assure you there will be a lot of people missing it if it were gone. Control nodes benefit from it the most, and it was especially useful back when Popup also used to inherit Control.
If anything, the oddity is that there's no corresponding shown signal. But this talk is beyond the scope of this PR.

[AdriaandeJongh]

I actually like the prior descriptions more, I feel out of the loop here. I do understand that top_level's existence makes the statement misleading, though.

Ah, dang. I made the changes quickly as I share @kleonc's view to keep the description correct and compact, but I can see how it makes it less easy to comprehend. How do you suggest I continue @Mickeon?

[Mickeon]

Sorry for a bit of delayed answer (if that was a concern).

The description can be compact, sure, but it also needs to be as meaningful and "digestible" as it can be with a few words. The previous description was too compact and didn't say anything much of substance, either.

[AdriaandeJongh]

It's tricky navigating the various different documentation styles of different collaborators, but I think my current wording is solid! Let me know what you think.

[Mickeon]

Just one more thing and I think this is excellent in my eyes.
Edit: Forgot to send.

[kleonc]

Added last small nitpick, otherwise it's fine to me. Thanks @AdriaandeJongh for the patience with us (me)! 🙂

[akien-mga]

Thanks!