Improved Theme Editor

[YuriSizov]

Supersedes #1438.

Describe the project you are working on

Godot Editor and games that could really use Themes for customization 🙂

Describe the problem or limitation you are having in your project

Current Theme resource and Theme editor are very limited in their functionality; provide only low level, often confusing UX and make users jump through a lot of hoops to get things done. This results in low discoverability of one of the most interesting features of the engine. This also makes the work for people who have found it unnecessarily more complicated.

Through information gathered in #1438 and other related issues I've pinpointed several key problems with the current workflow. Some of the problems, however, cannot be solved by the UI alone, but more on it after the main part.

1. The path from wanting to customize a control to actually doing it requires too many steps and prior knowledge about controls and their configuration.
2. Preview is hardcoded and may not represent states or layouts desirable, which means it has no real use a lot of the time.
3. The Inspector dock provides very little abstraction over the raw resource data. Navigating and using it requires a lot of jumping around multiple foldable sections, keeping in mind what you need and where you can find it.
4. StyleBoxes are monolithic and can't be easily shared/partially edited. Syncing multiple StyleBox resources requires a lot of manual labour.

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

To address these problems an overhaul of the Theme editor is required. I've already made two PRs that address the existing UI to make it more clear and reasonable (godotengine/godot#46593 and godotengine/godot#46808). For all intents and purposes, they are a part of this proposal as well as the following ideas and features.

1. Add an items panel to the Theme editor UI. It's core features would be ease of use, simplified navigation, use of grouping and quick tools to create, rename or remove definitions.
2. Add a picker functionality to Theme editor previews. Controls available for preview can be selected and automatically opened in the items panel, providing quick way to customize them. Tools to inherit/override specific properties of the base control should make the process intuitive.
3. Allow loading arbitrary scenes as previews. This way a UI designer can create a component zoo for the controls they use, fully controlling the content and the layout of the preview. Picker should work with it as well.
4. Add a quick custom preview builder. As an alternative to loading actual scenes the builder can be used to quickly create a mockup through visual means and configure available control to represent their specific states. Picker should work here as well.
5. In the new items panel provide a way to pin a StyleBox as a "leader". Editing the leader StyleBox would change all the compatible StyleBoxes within the same type.

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

In the items panel users can select the type and view all of its items. As existing controls map their class name to their item type verbatim, users can pick any existing control and see its inherit items. Users can override those items, change their values. Users can rename and create new items of each data type. And of course users can remove a type definition, undoing the override or removing their custom item.

2021-03-25_18-22-01.mp4

Control picking works similar to how it does in web browsers when using developer tools. Users can enable picking and hover over preview to look for the node their need. Clicking on it will bring up this node's type in the items panel. If the theme doesn't have a definition for the type, it would still appear in the panel, and users would be able to override its properties. Base properties can be hidden at any time, and users are free to override the entire type. Note, that some items are not copied when overrides are created, and this is by design.

2021-03-25_18-39-06.mp4

Custom scenes can be loaded as previews by simply selecting them in the file popup. To make working with custom scenes more versatile nodes now have an overridable property called (pending a rename) "node type", which be default maps to the control's class. It can be overridden in the Inspector to any other value, and this value would be pickable in the preview.

2021-03-25_18-40-20.mp4

The custom preview builder would provide users with a quick visual way to create a simple layout akin to the default one, but manually customizable. In the demo below it is not fully implemented, but the idea is there. Users pick one of the predefined layouts, and can then select and add controls from a list. Controls can be customized, and in a smart way too: e.g. instead of placing each individual button type from the list it can be switched from the button's properties panel. If the layout was changed after the some controls were added, they will be reordered to appear in the new layout.

2021-03-25_18-40-53.mp4

In the items panel StyleBoxes have a special option, where they can be pinned, making them lead over similarly typed StyleBoxes of the same type. With this users can edit the same property on all of the at once. This is a stopgap solution until we can come up with a better way to partially override StyleBoxes, but it should streamline things greatly as it is.

2021-03-25_18-43-38.mp4

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

This is a part of the editor UX, not a user-editable feature.

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

This is an improvement over the core editor plugin.

---

The work on this proposal is ongoing, but there is no PR yet. Everyone is welcome to experiment with the code, if you can build it yourself, from my in-dev branch: https://github.com/pycbouh/godot/tree/theme-editor-better-previews.

---

Most of the other problems voiced in the related issues require changes in the Theme resource itself or theming system in general. I will list my proposals for them below as a small bonus, but they are not a part of this here issue, and are instead ideas for going forward.

For example, it would be good to make "node types"/"types" depend on one another, thus making chains that can be used to extend one type with another type. This would allow for the custom types to extend basic types ("CustomLabel" depending on "Label", falling back on it for definitions it lacks). This means that when fetching a Theme item dependencies would need to be walked through until the first match is found. So this would be a somewhat breaking change to how theming works. It would make sense to clean up the names of items as well, so that you could depend two existing types one on another and something like font_color could be found in both of them.

Another problem users noted is lack of global overrides, like setting the default color for everything. Themes currently expose default font (and font size in 4.0), but that's it. Some way to interact with the default properties would be beneficial. A way to set theme item to the default value explicitly, whatever that value may be, can also be an interesting idea (kind of like "inherit" in CSS).

Then I also like the idea of theme states for controls (#2498). If implemented, it should fit nicely into the new Theme editor.

[vintprox]

Well-thought-out proposal! Being able to theme multiple custom nodes/classes in the isolated scene is a showrunner for me. I can tell because several states of the indication panel scene, that we handle, are just a little part of the game, and yet such indication is required. Right now, it's handled by script and custom StyleBox items packed in themes, which is dirty, yeah.

[2plus2makes5]

This proposal is really what we need! :D

Another thing, I'm really ignorant about this stuff so maybe i'm going to ask something stupid, but aren't there interface templates or programs that let us make custom interfaces? Wouldn't be cool if we were able to directly import them to Godot? Or at least some kind of packages with colors, fonts, custom icons etc? Or maybe being able to create an interface from an HTML page or something like that?

[YuriSizov]

With a lot of hard work you can make a tool or a plugin to adapt a UI designed in a specialized tool to Godot, probably with some trade-offs. But it won't be a part of core.

[Calinou]

It's already possible to use Godot to create themes programmatically. I made a proof of concept here: https://github.com/Calinou/godot-theme-generator

I can't guarantee that I'll be able to work further on it due to lack of time, though.

[2plus2makes5]

Thanks guys!

[rsubtil]

This proposal is really good! I love the future workflow from all the bits you've detailed, and I do have an idea related to the "Preview Scene" feature that I believe would be much simpler to both use and implement:

There would be two checkboxes; one for live previewing on the project (and therefore in any currently open scene above), and the other in the whole editor itself. While one, or both of these options were ticked, the Theme window would remain open at all times, as to not disappear and also be more obvious to the user they're in "preview" mode. I think, this way, it would be a more streamlined workflow, instead of having another smaller subwindow for previewing scenes.

Also, I've noticed the eyedropper tool works on loaded scenes as well, so this other idea I had might be more feasible than I imagined 😛 : what if you could use it anywhere? Both on any editor elements, and elements from the current opened scene? I think it would be even simpler for the user to find out how to customize a specific element if they can pick literally anything onscreen. I don't know how feasible is this, but it would be pretty cool 😉

[YuriSizov]

@ev1lbl0w Live preview is definitely an interesting idea, especially for the Godot editor itself. I think to an extend it can already work, if your scene uses the resource you edit or if your editor has your custom theme set in the settings (though I've not tried the latter). Not sure what the implication of a temporary override would be though. At the very least the whole editor would need to be redrawn as you edit the Theme, and that's not exactly cheap. Even in the Theme editor preview updates are timed instead of being live.

Maybe a live editor-wide preview would be a bit too much, but a quick way to apply the edited Theme to something without live updates can be good. I'll see if it's something I can address here or if it's better left for a future feature.

As for picker, technically, yes, it can be made to work with any set of controls. Not sure if I can make it pick through the 2D viewport of the edited scene, but picking from the editor should be definitely possible. This would be a quite clever way to straighten the editor Theme customization 🙂

[YuriSizov]

Because linked PRs don't pop up in your notifications even if you are subscribed to this issue:

My original plan (sans the preview builder) is now published as a PR and can be tested. In fact, I very much welcome everyone who's interested to test it.
godotengine/godot#49388

Additions like live preview or pick-any-control-in-the-UI picker discussed above would have to be implemented on top of it. I think there are enough considerations with them to require a proper proposal or at least research, and I don't want to postpone this rework any longer 🙂