Improve the default project theme

[Calinou]

The new default project theme uses StyleBoxFlat extensively for a more modern design and better scalability to multiple resolutions.

SVG icons are now used in place of PNG icons. While this does not allow for true vector-based icon drawing (icons are still rasterized at load-time), this makes the design work easier for contributors and opens the door to vector drawing in the future (e.g. with polygons or SDFs).

Like for editor icons, the SVG header file is now built automatically when a SVG file is changed. This removing the need for running make_header.py manually.

The Use Hidpi project setting has been removed in favor of a Default Theme Scale project setting, which allows creating the default theme at a higher/lower scale than the default. This can be used when designing GUIs with a high base resolution to ensure crisp visuals.

The new theme has slightly different metrics, which may result in elements being shifted around when porting 3.x projects (hence the breaks compat label).

Note: Unlike LineEdit, TextEdit will appear to have no visible focus outline because its focus outline is clipped by the main StyleBox's area (this is not about drawing order). We need to fix this in the TextEdit node, ideally before this PR is merged. See #32996.

This closes #25349 and closes #8636 (by implementing a more flexible mechanism).

Preview

On all screenshots, the first button is focused so that you can see how the focus outline looks.

Default resolution

Before	After

Fullscreen (canvas_items stretch mode)

The new theme scales much better to higher resolutions thanks to its StyleBoxFlat-based design.

Before	After

TODO

• Generate fallback images when the NanoSVG module is disabled.
  • Right now, if you disable the NanoSVG module, "Invalid image" errors will be spammed when the default project theme is created.
• Print a warning message when compiling Godot with the NanoSVG module disabled.
  • Alternatively, make NanoSVG a hard requirement for compiling Godot.

[YuriSizov]

Something's wrong with the texture progress control or with its surrounding container?

[Calinou]

Something's wrong with the texture progress control or with its surrounding container?

It looks as intended. It's just that the higher spacing makes it not fit anymore within the container, so its edge looks flush with the panel instead of having some padding. I'm not sure where this addtitional spacing comes from though.

[aaronfranke]

Overall this is really nice!

I'm not sure I like the scrollbars, and the other corners. Is there any program that has pointy edges on them?

It seems a bit bright. If we have white text we want to ensure the background is dark enough that people can easily read it. Can we make the background a nice even #444? We could potentially go even darker. (This was modified with GIMP)

[Calinou]

I'm not sure I like the scrollbars, and the other corners. Is there any program that has pointy edges on them?

Not that I know of. I'll reduce their radius to make them more square.

It seems a bit bright. If we have white text we want to ensure the background is dark enough that people can easily read it. Can we make the background a nice even #444? We could potentially go even darker. (This was modified with GIMP)

The panel's background is translucent, which is why it appears to be relatively bright against the clear color. I can make it slightly more opaque, which will make it appear darker.

[aaronfranke]

The panel's background is translucent,

Shouldn't it be opaque by default?

[Calinou]

Shouldn't it be opaque by default?

I can make it opaque by default, but one reason I made it translucent by default is that it makes multiple overlapping panels distinguishable out of the box (since they don't have borders anymore).

If panels are made opaque by default, the Self Modulate property could be used to adjust their opacity without overriding the stylebox.

PS: I updated the After screenshots in OP to reflect the latest changes:

• Lower corner radius on scrollbars.
• More opaque panels and buttons (50% opacity -> 60% opacity).

[ee0pdt]

The corners… is it possible to have rounded edges? I can’t think of a modern interface that has anything other these days.

I don’t mean to prevent anyone using this style, but just want to know if it’s possible to create an alternative

[Calinou]

The corners… is it possible to have rounded edges? I can’t think of a modern interface that has anything other these days.

Corners were rounded in an earlier revision of this theme, but there are currently several issues with rounded corners in StyleBoxFlat:

• When you enable antialiasing, the StyleBoxFlat's edges become blurry due to how StyleBoxFlat antialiasing is implemented. This makes the UI look less well-defined, both at low and high resolutions. This wasn't an issue at some point – it broke during the 3.1 -> 3.2 cycle and we didn't manage to find a good solution for it yet.
• When you disable antialiasing, rounded corners look bad at higher resolutions. Beleved corners look much better when antialiasing is disabled since there are only 45-degree angles.
• On particularly slow hardware (IGPs and mobile devices), displaying lots of StyleBoxes with rounded corners is slow. This can have a non-negligible performance impact on UI-heavy games. Beveled corners are much less expensive in this aspect.

If we manage to fix the issue with StyleBoxFlat antialiasing, I'd be OK with making corners rounded again.

In the Godot editor theme, corners are rounded and antialiasing is disabled. This combination works well because the Godot editor uses the disabled stretch mode, which means controls will not get larger as you resize the window (which makes antialiasing artifacts more visible here). However, in most projects, you'll want to use the 2d or viewport stretch mode to ensure the GUI scales well to all resolutions.

Edit: Corners are now rounded since #51442 was merged to fix StyleBoxFlat antialiasing.

[ee0pdt]

@Calinou that’s a fantastic reply. Thanks for the info

I guess that this is down to preference - and given the limitations I’d probably go with a one pixel radius and keep it simple.

If we could solve the anti-aliasing problem…

But either way, could we get your answer in the docs with some info on how to change the corner if one wanted to try rounded corners that would be most helpful I feel.

[Calinou]

But either way, could we get your answer in the docs with some info on how to change the corner if one wanted to try rounded corners that would be most helpful I feel.

The default theme is generated via C++ code, but I can probably add a few project settings to allow changing the corner radius, corner detail and antialiasing. I wouldn't go too far in the customization options though, as the default project theme is meant to be used for prototyping only.

[aaronfranke]

but I can probably add a few project settings to allow changing the corner radius, corner detail and antialiasing.

I don't think this is necessary. We should choose sane & clean defaults and go with the expectation that people will be using a custom theme on top of the default theme.

[groud]

Great work, having something a little big more modern is great.

Two points:

• Even if I like the fact we switch to a gray tone (it's indeed a lot better to fit various game themes), I kind of liked the fact that the theme was easy to recognize in the wild. Not a lot of projects are made using Godot so I think it's always useful to be able to recognize the default theme. Maybe we could find a balance by having a slight accent blue color somewhere? Likely on the buttons? I wonder if we could have a configurable accent color that could be applied to the whole theme easily (defaulting to a subtle blue).
• I think, like others, that I preferred the rounded corners. If it's not possible for now, I agree bevels are an acceptable workaround. The only place where it does not fit is the scrollbar, it looks a little bit aggressive and thus out of place. I would either make it look like other bevels or simply make it a simple rectangle (like most modern UIs now).

Anyway, 4.0 really needed such improvements. Great job!

[Calinou]

Maybe we could find a balance by having a slight accent blue color somewhere? Likely on the buttons? I wonder if we could have a configurable accent color that could be applied to the whole theme easily (defaulting to a subtle blue).

Unfortunately, I don't think it's worth the added maintenance effort. You have to remember that unlike the editor theme, the default project theme is included in every project. Any change that we make to it has the potential to break compatibility with existing projects.

I still think the new default project theme is easy enough to distinguish from Unity and Unreal Engine's respective default project themes, especially as soon as you start adding checkboxes and the like.

I would either make it look like other bevels or simply make it a simple rectangle (like most modern UIs now).

I toned down the corner radii for the scrollbars since I initially opened this PR. Did you look at the latest screenshots in OP?

[groud]

Unfortunately, I don't think it's worth the added maintenance effort. You have to remember that unlike the editor theme, the default project theme is included in every project. Any change that we make to it has the potential to break compatibility with existing projects.

I don't get it. Why would we change that? My idea was more to make it a project settings having an impact on the default theme. Even if we change the default color value, the last value could be stored in the project settings and kept. The idea would be simply to allow a simple customization if the default blue color would not fit.

That being said I don't know how feasible this is, maybe it would require another class inheriting the base theme? I don't know.

I toned down the corner radii for the scrollbars since I initially opened this PR. Did you look at the latest screenshots in OP?

Ah my bad, I did not see it. It's indeed better.

[aaronfranke]

@groud My idea was more to make it a project settings having an impact on the default theme.

There isn't really a point to do this. Users can just define a custom theme instead of modifying the default / base theme.

[Calinou]

There isn't really a point to do this. Users can just define a custom theme instead of modifying the default / base theme.

I'm inclined to agree with this too. We can't expect this default project theme to be a "one size fits all" solution. If you want to develop a polished game, you will have to create your own theme eventually. Merely changing the colors and corner styles is unlikely to be sufficient in this case.

A good-looking default project theme is just here to give a better first impression while prototyping.

[groud]

There isn't really a point to do this. Users can just define a custom theme instead of modifying the default / base theme.

Indeed, though the idea was to have something easily configurable. Not something where you would have to modify a lot of styleboxes only to change a single color.

I'm inclined to agree with this too. We can't expect this default project theme to be a "one size fits all" solution. If you want to develop a polished game, you will have to create your own theme eventually. Merely changing the colors and corner styles is unlikely to be sufficient in this case.

Yeah, I agree. I'm indeed not talking about the situation for a polished game, I am simply wondering if we could make the default theme a little bit configurable, with a single color, nothing more. It won't be sufficient for any finished product of course.

A good-looking default project theme is just here to give a better first impression while prototyping.

Well, yeah, that's also why I believe we should likely make the default theme a little less bland. Because, as you know, a lot of those prototypes and tools end up used everywhere anyway.

I think my main issue right now is that we have no solution in-between using the default theme and fully making a new one. There's kind of a gap between what the user would want (slightly changing the color of the default theme) and what they need to do (override all elements of the default theme). The difference in terms of workload is quite big and I believe is something that should be addressed.

[aaronfranke]

What if we inverted the brightness? Just an idea, not sure if it's better for general purpose usage. Here are some images lazily edited with GIMP. Vs old theme:

Before	After

Vs this PR's theme:

Before	After

[YuriSizov]

I think it's hard to compare against a monotone gray background. It would be nice to see it over some game elements, so that alpha is more readable.

[YuriSizov]

I've done additional work here to help Calinou, he should be able to merge my changes that add the remaining styles and icons.

While working on it, I've run into a few cases of weirdness in some controls, which I do not believe are related to the theming changes and should be fixed in another PR, but I'd still like to mention it here for now:

In FileDialog a header subtitle is used, but it looks strange in default theme. Maybe we need to play around with it more, or maybe this dialog shouldn't use a header here at all. Also note the hidden files visibility icon. You can't tell if it's on or off. We should better distinguish the states, and I propose to use the same icons we have in the gizmo visibility/scene dock in the editor for the "off" state.

CodeEdit seems to have issues calculating the gutter. Breakpoints and bookmarks lay over each other, and bookmarks are cropped for some reason (the icon is in fact wider, almost square, and has round corners).

Something is wrong with Tree and editable items. After focusing on the item for a few moments, an overlay appears over it, and the editable state is no longer accessible. Happens with every editable cell that has line edit, at least.

[Calinou]

I pushed a commit that includes @pycbouh's squashed changes. I updated the comparison images in OP.

I noticed that some default project theme styles creep into the editor theme, as evidenced by window margins being increased when you increase Default Theme Scale then restart the editor:

I haven't been able to check whether this occurs in single-window mode yet.

---

I've changed the code a bit to support building with module_svg_enabled=no, but it seems the SVG module is always considered disabled now. I have no idea why…

Disabling the SVG module results in a size reduction of about 80 KB in a Linux release export template (production=yes and stripped), so it's not negligible for mobile games.

[akien-mga]

You'll also need to sync the class reference next time you rebase.

[YuriSizov]

The lights are green! I think it's good to go

[akien-mga]

Thanks!