Godots theming system is very simple. It is still a game engine. Styleboxes are assigend to different states of Control-Nodes. There is no cascading, no shared variables. This makes it very easy to understand, and results in very little complexity. But also comes with a cost. Setting up themes is super tidious. For examle a color change requires you to update hundreds of values.
It is the Goal to desing a theme editor, which will generate a theme with systems, like a color palette, so that we get the best of both worlds. The simplicity of godots theming, and a advanced theming structure when setting up a theme using the theme editor. There is a big amount of freedom and creative ideas to make creating themes a pleasure, while still keeping the core architecture as simple as possible.
The editor theme hides those shortcomings, by creting a new theme on each startup, and when theme settings change. A script than computes the colours, the dpi scales and creates a new theme. This in conjunction with the generation of the icons (svg->png) on each sturtup is a unecassary performance hit (mostly influencing the startup time).
Using coustom themes in your own projects is very cumbersome atm. The theme editor ux is really bad. And as soon as you want to make a batch change (darken every color for example) you are basically screwed. The result is, that even for your own projects the only feasible solution is to also write a Script which generates a new theme file.
The
- Icon max size in theme properties for buttons...
- A system for shared/computed_properties (color, dpi values are a good example that could be shared) This can also be super powerful in multiple cases... basically something similar to the driver system in Blender. (Example: The width of a node affects its color (from green to red) for a health bar without coding.)
- Color modulation per texture, so that icons dont need to get regenerated on each theme change. Just the modulation color needs to change.
- Cascading styles. A Override Stylebox, which reuses the style of another stylebox but overrides only specific parameters.
- A better theme editor (UX). To make it easy to setup a new theme and have an overview of the shared/computed variables. Also a stylebox editor could be useful, with handles for changing border width, corner radius...
- Refactoring of the Dpi system. Currently everything is handeled by the editor itself. A godot project does not have the same dpi switching. When the theme handles the dpi scale this could change. Fonts, margins, constants all can be computed based on the dpi setting and the entire theme will update when a dpi_scale varibale of the theme gets changed.
- should there be a stylesheet (css) system for godot themes. This is a very established system of handling complex styles. NO, the refactor should stay fairly simple and keep the current systems. There should not be changes to every singe control node.
- Should the computed properties be a theme only feature or should/ could it be godot wide? What is the best implementation? Current idea is to allow resources to also have properties. these can be used for any object property.