Add toggling visibility of multiple nodes in scene tree by click-and-dragging

[keestak]

• Closes Allow toggling visibility of several nodes in the Scene tree dock by click-and-dragging (and/or on all selected nodes at once) godot-proposals#5488

Other software such as Blender, Photoshop, and Aseprite let you click and drag over layer/object visibility icons to toggle the visibility of multiple objects at once. I think this is a nice quality-of-life feature that improves workflow in the editor. This PR implements that feature for the scene tree dock.

[Calinou]

Tested locally, it works as expected.

simplescreenrecorder-2025-01-25_16.23.10.mp4

Some feedback:

• The pressed icon background is only present on the first clicked icon, not the icons you've dragged the mouse over. I feel this background should display on all icons your mouse has gone over until you release the mouse button.
• Remember to update the class reference XML and fill in the descriptions as per the documentation.

[keestak]

• The pressed icon background is only present on the first clicked icon, not the icons you've dragged the mouse over. I feel this background should display on all icons your mouse has gone over until you release the mouse button.

I'm not sure there's an easy way to do this, especially without adding unnecessary clutter to the tree and scene tree editor classes. It would be a lot easier to just make the pressed icon background for the first clicked icon become 'unpressed' when the click drag happens (so all the icons appear 'unpressed' during the drag). Would that be acceptable?

[keestak]

I went ahead and made it so the background of the initial button becomes unclicked when the click-and-drag happens. It looks like this now:

I think this makes sense because leaving the button with a clicked background implies that it will receive a click event once the mouse button is released (as it does when you mouse down on a button, then drag off the button, then mouse up - the button will still be clicked, and that's not the case during click-and-drag). It's also just a two-line change to do this, while making all the buttons show as clicked during the event would require a lot more additions. Hopefully that's all alright.

I also updated the class reference, so everything should be good now I think...

[KoBeWi]

The behavior is fine, but the implementation is too complex. It should not modify Tree, or at least not introduce new API.
I think it can be implemented entirely in SceneTreeEditor, with a combination of button_clicked and gui_input signals.

If it turns out impossible, at least button_click_dragged should be removed. It's emitted with every mouse movement, which should not be required. Also instead of button_click_drag_end you could just stop dragging when mouse button is released.

[keestak]

@KoBeWi
Someone in the issue I mentioned in my initial post said that it would be nice to have Tree support click-and-drag as a built-in feature, so that was part of my approach; maybe I should've asked around more. It is possible to do most of this in SceneTreeEditor only - because all of this functionality stems from gui_input, the relevant parts can just be re-implemented in SceneTreeEditor only which would remove all the new api I added (I am a little concerned about creating unnecessary duplicate code though). That would mean that I wouldn't be able to change the way Tree draws its buttons though, so I'm not sure there would be a way to control the clicked background of the button when dragging starts, which means that it would visually look like the first gif I posted. I do think that's a minor visual detail, but it's worth considering.
If it sounds good to you, I can move all the functionality into the SceneTreeEditor class and avoid changes to Tree or additions to the API.

Also for the record, the button_click_dragged signal emits every time a button becomes hovered during the click-and-drag event, it doesn't emit every frame the mouse is moved if that's what you meant.

[KoBeWi]

I'd wait for feedback from other maintainers. Maybe extra signals are fine, especially if it avoids code duplication and allows better visual feedback.

[KoBeWi]

The new functionality is fine, but the implementation might deserve more discussion.