Structured Theme Key Access for UI Styling in Code

[CG-Tespy]

This proposal aims to enhance developer experience when working with Godot’s UI theme system by introducing structured access to theme keys in code.

The Problem

Godot’s theme system relies heavily on string-based identifiers to reference styleboxes, colors, and constants (e.g. "focus", "selection_color", etc.). This works fine in GDScript, but in C#:

• It's error-prone due to lack of compiler validation
• Offers no autocompletion or discoverability
• Leads to potential runtime issues from typos or incorrect keys

For developers building modular, metadata-driven, or designer-friendly UI systems, the current workflow limits productivity and maintainability.

The Proposed Solution

Introduce a built-in enum, static class, or generated key registry that exposes all known Theme property identifiers used by Control nodes. For example:

public static class ThemeKeys
{
  public static class LineEdit
  {
    public static string FocusStyleBox => "focus";
    public static string SelectionColor => "selection_color";
  }
  // So on, so forth
}

This would:

• Improve IDE support and autocomplete in C#
• Reduce hard-coded strings and improve code readability
• Enable tooling extensions and wrappers (e.g. ApplyPreset systems)

Who It Benefits

• Developers building custom UIs and editor tools, be it with C# or GDScript
  • While string-based theme keys are generally workable in GDScript (thanks to its dynamic nature), they remain error-prone and lack editor tooling support. Introducing structured keys could benefit users across both languages, especially in tooling or editor-facing workflows.
• Game and tool creators leveraging data-driven styling
• Contributors improving runtime UX consistency across controls

Why It Matters

Godot’s design philosophy already celebrates clarity and flexibility. This addition would elevate its theme system to match that spirit, especially for those crafting extensible UI frameworks or editor integrations. Even an initial static class for standard controls would go a long way toward reducing friction and enabling richer customization pipelines.

[Calinou]

• Related to Enable using layer names instead of int for setting collision layers #3930 (comment).