Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add 'hovered' signal on BaseButton which is emitted if the Mouse hovers the Button when NOT disabled #9100

Closed
ch0m5 opened this issue Feb 15, 2024 · 3 comments

Comments

@ch0m5
Copy link

ch0m5 commented Feb 15, 2024

Describe the project you are working on

A CRPG, therefore a game with a ton of UI that the player interacts with mostly using the mouse.

Describe the problem or limitation you are having in your project

BaseButton has a disabled state where, on most case scenarios, the Button is expected to do nothing and not react to inputs directly made on it, such as pressing the button. However, positional mouse inputs are handled through mouse_entered and mouse_exited, inherited from Control, which does not account for this.

Therefore, for virtually every single Button, I need to check within mouse_entered whether the button is enabled or not for stuff such as playing UI audio queues or do whatever I want to do when the button is hovered, but not disabled. This is already a core feature of BaseButton through its UI Themes, due to the Button applying the Hover style when hovered, but not doing so if it is disabled.

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

Add a hovered signal on BaseButton which emits() if the mouse hovers the Button and the Button is not disabled. This would be a quality of life improvement that, in my opinion, feels common enough to have, avoiding the necessity of having to go through mouse_entered which disregards this extra layer of information.

As mentioned above, UI Themes for Buttons already do this: there is a Theme for Hovered which is only set IF the mouse is hovering and the button is not disabled, we just need a signal to do similar actions through scripts.

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

This is how I would expect to get when I connected the hovered Button signal to an owner script through the editor:
func _on_hovered() -> void: pass

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

Yeah, by using mouse_entered and checking if disabled is true or false within, but this requires for whichever script is reacting to the signal to have access to the Button in order to check its disabled var, when more often than not you just need to know if the Button was being hovered while enabled.

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

BaseButton has a bunch of core signals: button_down, button_up, pressed, toggled. All referring to basic interactions with the Button through the Mouse or Shortcuts. I feel hovered should also be available, given it falls under the same group: a core interaction the Mouse has with the UI, hovering it when enabled.

@Mickeon
Copy link

Mickeon commented Feb 16, 2024

The workaround is extremely simple, I feel, and it's not an use-case so common it warrants its own signal as a Quality of Life.
The signal may also be more specific than desired. For example, sometimes it's worth listening for focus, not just the cursor hovering.

Keep in mind that if you already have a script attached to these custom buttons, you don't need to connect the mouse_entered signal through the editor (if that is the annoyance). You may also do it on _init, or _ready in code.

@Calinou
Copy link
Member

Calinou commented Feb 16, 2024

Therefore, for virtually every single Button, I need to check within mouse_entered whether the button is enabled or not for stuff such as playing UI audio queues or do whatever I want to do when the button is hovered, but not disabled.

I feel that particular use case warrants a built-in solution given how common it is.

@ch0m5
Copy link
Author

ch0m5 commented Apr 3, 2024

Last reply is very reasonable. Closing issue due to being, arguably, a duplicate and to avoid adding onto the already massive pile of existing open issues.

@ch0m5 ch0m5 closed this as not planned Won't fix, can't repro, duplicate, stale Apr 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants