Replies: 1 comment 1 reply
-
I think we need to handle this differently. We should make it so mouse-produced focus doesn't have a visible outline by default, as I proposed in #6577. This way, you still preserve expected accessibility behavior (clicking with the mouse defines focus), but it doesn't visually get in the way. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi there,
I'm making an app primarily for mobile that I might like to port to PC someday. For a quiz minigame, if the user is using touch or a mouse, it makes little sense to grab the focus of the last selected button. However, if the user is useing a keyboard or a dpad, focus helps the player know which button they are about to press:
Currently, the focus modes are:
None
Click
All
Where all includes click, dpad, and keyboard. Would it be useful to others to provide a 4th option: dpad_and_keyboard?
I was hoping it would be a relatively simple change, and tried to make a PR. Unfortunately, I couldn't find where the logic for the click modes are implmented. I did find the following files which would likely need to be updated:
https://github.com/godotengine/godot/blob/c8c483cf57a768110fce57e509f9b855e69d34b7/doc/classes/Control.xml#L1140
https://github.com/godotengine/godot/blob/c8c483cf57a768110fce57e509f9b855e69d34b7/scene/gui/control.cpp#L3607
https://github.com/godotengine/godot/blob/c8c483cf57a768110fce57e509f9b855e69d34b7/scene/gui/control.h#L62
Beta Was this translation helpful? Give feedback.
All reactions