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

Shift + ui_accept does not work with pressed signal on button #96604

Open
Giganzo opened this issue Sep 5, 2024 · 4 comments
Open

Shift + ui_accept does not work with pressed signal on button #96604

Giganzo opened this issue Sep 5, 2024 · 4 comments

Comments

@Giganzo
Copy link
Contributor

Giganzo commented Sep 5, 2024

Tested versions

Godot v4.4.dev1
Godot v4.0.stable

System information

Fedora Linux 40 (KDE Plasma) - Wayland - Vulkan (Forward+)

Issue description

Shift + ui_accept (same with Ctrl, Alt) does not work with pressed signal on button when usign this code:

This code works if you switch KEY_SHIFT to KEY_A

func _on_pressed() -> void:
	if Input.is_key_pressed(KEY_SHIFT):
		print("Shift was pressed")

This works in Godot 3

Steps to reproduce

connect pressed signal to a script
see code above
grab button focus
press shift + ui_accept
nothing is printed

Minimal reproduction project (MRP)

shift-and-accept-in-pressed.zip

@AThousandShips
Copy link
Member

AThousandShips commented Sep 5, 2024

This is by design, the button only accepts exact event clicks:

bool ui_accept = p_event->is_action("ui_accept", true) && !p_event->is_echo();

So adding shift to it is invalid unless you add that to ui_accept

The question is if it should be strict with mouse presses, and I don't think it should, there's plenty of validity to allow modifiers for mouse clicks but not key clicks IMO

I'd suggest opening a proposal to add a modifier mask to BaseButton to restrict modifiers with mouse events instead, defaulting to allow all modifiers to avoid breaking compatibility

@Giganzo
Copy link
Contributor Author

Giganzo commented Sep 5, 2024

The question is if it should be strict with mouse presses, and I don't think it should, there's plenty of validity to allow modifiers for mouse clicks but not key clicks IMO

Why should you not allow a keyboard user to activate the modifier click on the button?

This is by design, the button only accepts exact event clicks:

Why does it then work with KEY_A as an example?

@AThousandShips
Copy link
Member

AThousandShips commented Sep 5, 2024

Why should you not allow a keyboard user to activate the modifier click on the button?

Because UI elements are usually activated with exact actions, otherwise combinations wouldn't work generally, what if you set ui_accept to Shift + Enter, then buttons would accept on Enter alone, which would be a bug

Why does it then work with KEY_A as an example?

Because you're checking if something else is pressed, it activates the button whenever ui_accept is pressed, not only when nothing else is pressed, the Input.is_key_pressed just checks if the key is pressed right now, it doesn't check that it was part of activating the button

@Giganzo
Copy link
Contributor Author

Giganzo commented Sep 5, 2024

Why does it then work with KEY_A as an example?

Because you're checking if something else is pressed, it activates the button whenever ui_accept is pressed, not only when nothing else is pressed, the Input.is_key_pressed just checks if the key is pressed right now, it doesn't check that it was part of activating the button

I see that now, thanks!

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

2 participants