More flexible TextureButtons

[HexStar27]

Howdy!

The focused texture of the TextureButton node is displayed over the base texture. This make sense for outlines but it isn't enough otherwise. I think the problem lies in the hover and focused texture behaving differently (one swaps, the other displays it over).

As an example, let's say a game supports both mouse and gamepad input (a shooter for example), then, navigating through a menu would yield different visual results between these two input methods, since focused (with joystick) works differently than hover (with mouse).

Looking in forums it seems like people is specting it to swap instead of being displayed over. I think this shows how the default (and only) option seems counter-intuitive.

I get that changing the default behavior is probably not a valid way to solve this, what i suggest is to add a boolean variable that toggles whether to display over or swap the sprite. This way, the node works exactly the same as in previous versions, but also let people have the choice to change its behavior.
We may call the mentioned variable "Use Focused As Swap" for example.

What do you think? If any of you come with a better idea to solve this "visual inconsistence" between input behaviors during menu navigation, please comment about it!

I'm no expert in the engine (the most complex thing i have done is a simple test extension) but this seems like an easy thing to do, if this gets approved i can try making a pr for it.

[aXu-AP]

I think toggle should be added for both. The lazy developer in me wants always use just a simple transparent gradient as hover/focus overlay, not needing to make separate hover versions of buttons.
As for naming, I would go for overlay_focused and overlay_hover.

[HexStar27]

Oh, make sense.
I like it, and implementing both should be as easy as just for the focused texture

[Calinou]

As an example, let's say a game supports both mouse and gamepad input (a shooter for example), then, navigating through a menu would yield different visual results between these two input methods, since focused (with joystick) works differently than hover (with mouse).

To me, this needs a different approach than changing how the focus highlight is drawn. Focus should always be an overlay for accessibility reasons, as it shouldn't hide other states such as hover or pressed.

CSS resolved this years ago with :focus-visible, which draws the focus highlight only when focus was induced by the keyboard or gamepad, but not mouse or touch. This solution would also work for all Control nodes and wouldn't be limited to just TextureButton with a disabled-by-default property or theme item.

[HexStar27]

I think I see how focused should be always an overlay now (even though Unity doesn't do it anyway), and the different aproach you shared makes sense this way.
Maybe I should use a workaround in my project and make the UI response animation based.

CSS resolved this years ago with :focus-visible, which draws the focus highlight only when focus was induced by the keyboard or gamepad, but not mouse or touch.

I don't quite understand how this helps to make both input actions visually equal tho.