Make "switch on hover" a feature of all buttons, not just MenuButton

[YuriSizov]

Describe the project you are working on

Godot Editor

Describe the problem or limitation you are having in your project

While working on godotengine/godot#63358 I've run into the need to have a switch on hover behavior for a custom popup-using button. The reason to have it is simple, when you work with the toolbar, as a user, you want all expendable submenus to switch on hover. It makes working with the toolbar quicker and more intuitive, as you look for the tool or setting you want.

The problem is, currently this behavior is implemented as a part of the MenuButton exclusively, so to extend it to something else the new node needs to be related to it. I initially implemented PopupButton as a base class that took care of this shared functionality leaving MenuButton intact. But that quickly bloated the PR with a lot of unnecessary changes that had long-reaching implications. So I scrapped the idea, but would like to revisit it with this proposal. For the time being the new buttons in godotengine/godot#63358 don't have this switch on hover logic and thus may be lacking some of user-friendliness.

Another issue with how the behavior is implemented is that it is parent based. This means that, for example, in our editor's toolbar only the buttons sharing the same parent can be switched on hover. But to the user the toolbar is one unified row of buttons with only superficial visual separation. It doesn't make sense to not be able to hover from any one button to another and have this logic work. Even more, we may want to extend it to all popup-using buttons visible, similar to how the Alt button works in Windows applications, I guess.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

First of all, the necessary logic should be moved to either button.h/cpp or base_button.h/cpp. I initially wanted to do that in the PR, but the implication would be even greater that way. It should be relatively easy to do though. On the plus side, any button would be able to implement some sort of switch-on-hover logic, even if it doesn't use any popups. Most importantly, all popup-using buttons will share this behavior without overcomplicating their inheritance chain.

To implement the behavior on the scripting side as well as on the engine side we should add a new signal, e.g. "switched_on_hover", which would be emitted in the same way the current methods make the popup appear. A counterpart signal may be needed to switch off when the hover leaves the current button to another. Virtual methods are another possibility, of course. In Godot 4 either option should be trivial to add.

For the parent-based issue, the solution is also simple. We should use node groups. A new property can be added to indicate which node group should be used for this behavior in each individual button. This may require adding a NodeGroupPicker inspector plugin to make this process easier to the users.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

See above.

Basically, any button would be able to enable the switch on hover behavior. The exact logic would be left for each control to implement individually. Built-in controls like MenuButton or ColorPickerButton can enable it by default, or at least do so in the editor environment.

An extra property would be needed to define the node group that should be checked when the behavior happens to be triggered. Either a signal or a virtual method should be exposed to let each button to define its behavior, both for switching on and for switching off.

If this enhancement will not be used often, can it be worked around with a few lines of script?

The behavior in the MenuButton can be replicated, but the problem is that the code in menu_button.cpp is isolated and cannot be affected without dirty hacks (in the engine) or at all (in scripting). So a custom system can be scripted to replace the existing behavior completely, but IMO it doesn't make sense when we already have the backbone of this feature and only need to share it.

Is there a reason why this should be core and not an add-on in the asset library?

Same as above, can be made as an external addition to replace the existing system, but that seems counterproductive.