X Tutup
Skip to content

Add setting for when to show the focus state for mouse input#110895

Merged
Repiteo merged 1 commit intogodotengine:masterfrom
Giganzo:input-focus
Oct 22, 2025
Merged

Add setting for when to show the focus state for mouse input#110895
Repiteo merged 1 commit intogodotengine:masterfrom
Giganzo:input-focus

Conversation

@Giganzo
Copy link
Contributor

@Giganzo Giganzo commented Sep 25, 2025

Replaces the gui/common/always_show_focus_state from PR #110250 with a new setting that have 3 different options for when do draw the focus state for pointer events. This adds support for showing focus state for controls with keyboard input.

Screenshot_20250924_170855
Screencast_20250924_171159.webm

Might be a good idea to have these settings for the editor itself too.

@lostminds
Copy link

I think some sort of setting like this is a very important addition from a UI/UX perspective after the changes in #110250 . As I understand it that PR changed things to make it easier to avoid showing unwanted focus rings around buttons when you're not using keyboard/controller navigation. But this misses the other big use of focus highlights of controls to show the user where keyboard entry or other secondary editing is currently directed (as in what text field you're currently editing, what color well is active when picking a color or other similar custom input controls). For these cases I think it's expected and needed for the control to get and show focus when clicked with a mouse, and unfortunate if this current functionality would break in 4.6.

If I understand it correctly however, this PR would only add a possible exception for TextEdit and LineEdit explicitly, so it won't be possible to use for custom Controls where you want or may be relying on the old behavior?

Perhaps this whole showing focus behavior could be handled better via something like the control focus modes instead, allowing to set the behavior per control with a default rather than project wide with project settings like this?

@YeldhamDev
Copy link
Member

If I understand it correctly however, this PR would only add a possible exception for TextEdit and LineEdit explicitly, so it won't be possible to use for custom Controls where you want or may be relying on the old behavior?

Whether a custom Control shows focus or not depends entirely on you. Hidden focus is only ignored if you use has_focus() with true, so if you want your Control to always show it, you still can.

@lostminds
Copy link

Whether a custom Control shows focus or not depends entirely on you. Hidden focus is only ignored if you use has_focus() with true, so if you want your Control to always show it, you still can.

I'm not sure I follow, I assume the engine would call has_focus() with true in this case to determine if it should show the focus ring? And as it's a built in class method has_focus can't be overriden to change what it returns in my custom control class. Say I have a custom control inheriting Button that brings up some selection interface (like a color picker). Currently if I set this to focus_mode ALL it will get a focus ring when it is clicked, which is what I want. This will also disappear as expected when changing focus to some other control. But as I understand it this will no longer happen after #110250 (with default project settings) as the control received focus with from a mouse click, which will not be shown?

@YeldhamDev
Copy link
Member

Say I have a custom control inheriting Button that brings up some selection interface (like a color picker).

You can still force an existing Control that handles its own focus to show it by using grab_focus(false).

@YeldhamDev YeldhamDev modified the milestones: 4.x, 4.6 Oct 21, 2025
@Repiteo Repiteo merged commit e870cd9 into godotengine:master Oct 22, 2025
20 checks passed
@Repiteo
Copy link
Contributor

Repiteo commented Oct 22, 2025

Thanks!

@Giganzo Giganzo deleted the input-focus branch October 22, 2025 10:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants

X Tutup