godotengine
Clarify CanvasItem's visibility signal descriptions (followup)
Follow-up to: https://github.com/godotengine/godot/pull/97223#discussion_r1771560521
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.~~
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.
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.
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?
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.
