-
-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improved Theme Editor #2505
Comments
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. |
This comment has been minimized.
This comment has been minimized.
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? |
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. |
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. |
Thanks guys! |
@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 🙂 |
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. 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 🙂 |
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.
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.
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.
The text was updated successfully, but these errors were encountered: