Named Theme Colors

[Qubus0]

When creating and theming interfaces, especially when using lots of StyleboxFlat for a more modern look for non game applications, there will be a lot of colors, but not many unique ones. That's where a small palette comes in handy.

This palette usually has just a few colors you want to use everywhere - but in themes you have to drag your hex codes through everything, manually. Of course you can use the swatches and recent colors to help set them, that is nice.

The issue arises if you want to either change or offer a secondary palette. Now what. Duplicate the theme and change everything by hand? Programmatically access each font-, stylebox background-, border-, and colorrect color to have quicker access to it in the future? Both very painful and time consuming. Might be easier to use a color swap shader. if the antialiasing wouldn't be weird with it. That's why i dropped the idea of interface theming.

Now, coming from scss, where everything can be a variable, it would be nice to be able to create something like "design tokens" or named values. For example:

Which would then be usable in other theme properties, instead of setting the raw value. When the value of a token changes, all theme properties referencing it would change with it.

My main interest would be colors here, but of course this can also extend to other things like fonts, textures, sizes (which would make other design systems easier, like defining large, medium and small sizes for spacing to be used in margincontainers or stylebox contentmargins).

While you can somewhat already do something like this with entire styleboxes by copying a singular stylebox and not making it unique, it's quite awkward to use. And you can't swap it out for a different stylebox everywhere (like flat to texture).

Slightly more usable: for textures you could get hacky and reference one AtlasTexture and then swap out the atlas texture resource, instead of using the texture directly. And similarly for fonts you could use a font variation as reference and swap out the base font, instead of using the font directly.

None of these hacks work for colors (or sizes) though.

Now, thinking about how this could elegantly fit into the rest of the theme system is a little challenging. We'd essentially need to have two "modes" for each theme property, either being the normal raw value, like it is now, or a string (which also isn't nice, some reference would be better). Interface-wise that would probably need an extra toggle on all the theme inputs. Little strange. Or maybe it's toggled through a right click context menu, but that makes the feature pretty hidden.
Maybe there are more elegant ways to do this - let us know if you think of one :)

[ArchercatNEO]

I was thinking of how graphical toolkits like gtk and qt do for themeing. There are things like base16 too so could we apply some of those concepts here?

Maybe we could extend Theme to add more features (or well set values based on these variables)? So when we extend Theme we can define these generic variables and then programatically it propagates values to all the relevant Control nodes. Concretely what that would look like is that Theme is the blank slate with no propagation but with let's say ThemeBase16 (which could be a core or an addon class) adds 16 new "variables" in a new dedicate tab (like color/text/etc have now). Then ThemeBase16 would programatically propagate these 16 values to buttons/text inputs/etc. This way we could have various Theme extensions like ThemeGtk, ThemeQt, etc which would allow easily loading and switching themes as well as variable propagation.

As for custom nodes and custom themes we could just extend the Themes again, so if you have InventoryWidget or smth with it's own theme properties, ThemeGtk could be extended to propagate it's variables to InventoryWidget. Does that sound "automatic" enough?

[ArchercatNEO]

I've got a workaround with a script:

@tool
class_name ThemePropagated extends Theme

@export var text_color: Color:
  set(value):
      text_color = value
      set_color("text_color", "Button", value)
      set_color("text_color", "Label", value)

With this theme, you can set only one value (text_color) and have it propagate to all the nodes you need. Understandly doing this for every single control with a text_color is way too much effort to be a "simple" workaround but is this worth putting in core (with a good coverage for similar settings) or more fitting for an addon? (Or maybe this isn't even what you wanted?)

[Qubus0]

yeah this is essentially a nicer way to do what i meant with this

Programmatically access each font-, stylebox background-, border-, and colorrect color to have quicker access to it in the future?

as soon as the theme grows, all of this gets out of hand.

[ArchercatNEO]

Would creating a huge theme extension and landing it in core/addon (so that the "out of hand" is handled elsewhere) work well enough for you?

[Qubus0]

like, just a list containing all the possible theme style colors and stylebox colors for every node type (except custom theme variations of course)?

i suppose an extension which would allow right clicking a theme property to add it to this type of theme extension could work. From experience this type of script modification is really hacky tho.

but perhaps it could be added to a dictionary on the theme resource, for example this unwieldy structure. maybe it can be better but yeah. especially with the sylebox subproperties..

var palette: Dictionary[Color, Dictionary] = {
	Color("#000"): {
		Button = ["text_color"],
		ButtonPrimary = ["text_color"],
		Label = ["text_color"],
	},
	Color("#fff"): {
		Button = ["theme_styles:normal:bg_color"],
		PanelContainer = ["theme_styles:panel:bg_color"],
	},
}

and this would really not be nice to edit with the current inspector, so the plugin would be required to reduce that