More consistent, detailed, and intuitive theme properties

[scottfoxyt]

Describe the project you are working on

A cross-platform sandbox game with lots of UI.

Describe the problem or limitation you are having in your project

The default theme properties for buttons, sliders, and other control nodes are inconsistent and limited, making the process of creating visually consistent cross-platform UI and good visual feedback obtuse and unintuitive for the developer.

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

Rework and expand the default theme properties to make the process of creating visually consistent cross-platform UI and good visual feedback better and more intuitive for the developer.

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

The following is a mockup of the potential changes.

Button styles (other groups such as icons and font colors would have similar or the same variations)
- normal
- highlighted
- disabled
- disabled_highlighted
- pressed (following variations exist because of the ability to toggle)
- pressed_highlighted
- pressed_disabled
- pressed_disabled_highlighted
- focused (overlay)

Check button icons (check boxes would have similar or the same variations)
- unchecked
- unchecked_highlighted
- unchecked_disabled
- unchecked_disabled_highlighted
- unchecked_pressed (exists for better visual feedback during a click when using without button as background)
- checked
- checked_highlighted
- checked_disabled
- checked_disabled_highlighted
- checked_pressed (exists for better visual feedback during a click when using without button as background)
- (mirrored variants)

Scroll bar styles
- grabber
- grabber_highlighted
- grabber_disabled
- grabber_disabled_highlighted
- grabber_pressed (exists for better visual feedback during a click)
- gutter (more intuitive name than scroll)
- gutter_highlighted
- gutter_disabled
- gutter_disabled_highlighted
- focused (overlay)

Slider styles
- grabber_trail (more intuitive name than grabber_area but may be unnecessary)
- grabber_trail_highlighted
- grabber_trail_disabled
- grabber_trail_disabled_highlighted
- gutter (more intuitive name than slider)
- gutter_highlighted
- gutter_disabled
- gutter_disabled_highlighted
- focused (overlay)

Slider icons
- grabber
- grabber_highlighted
- grabber_disabled
- grabber_disabled_highlighted
- grabber_pressed (exists for better visual feedback during a click)
- tick
- (other tick variations are probably excessive but may be beneficial)

Line edit styles (other groups such as icons and colors and other nodes such as text edit and code edit would have similar or the same variations)
- normal
- highlighted
- disabled (or read only)
- disabled_highlighted
- focused (overlay)

Other nodes I did not have time to mockup
- Item list
- Tree
- Graph node

Highlighted variations would be shown when hovered and/or focused, just like scroll bars currently already do.

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

It is possible to work around with a decent amount of code but it would be used incredibly often as it is a rework and expansion of the default theme properties. The lack of consistency currently is also a concern.

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

This is about reworking and expanding the default theme properties to make the process of creating visually consistent cross-platform UI and better visual feedback better and more intuitive for the developer.

[FonkinS]

There should also be some form of hierarchy. What I mean is, if I’m making something quick for a Gamejam game, I might have just enough time to make 3 different styles. Normal, Hover and Pressed. (and maybe Disabled) I’m not gonna want to go through and make one specifically Pressed_Disabled_Highlighted. The engine should in that case, if I notice that I haven’t set anything, default to my Disabled, instead of the often ugly looking default Godot style.

[scottfoxyt]

I was thinking of this as well! The only issue I see is that different developers may have different heirarchies in mind. It may be better for the developer to just be expected to reuse styleboxes or colors or whatever else for those variations if they don’t feel they are needed for their project instead of letting the engine decide for them.

[dalexeev]

• See also #2498.

[Andikki]

If there's a focused button (you navigate to it with keyboard), and then you hover over it with a mouse, will there be any visual change? Looks like there wouldn't be, because you suggest that highlighted is applied for both focused and hovered, so it will transition from highlighted to highlighted - i. e. no change. Hover should probably stay its own concept, separated from focus.

I agree that the current Godot implementation is not enough (for example, hover only applies to normal unpressed buttons, but doesn't do anything in pressed or disabled states).

Also, focused (overlay) isn't really enough. See #8134