How to synchronize font and font size across different node types collectively now that DynamicFont is gone

[Overvault-64]

Describe the project you are working on

Every project that has UI

Describe the problem or limitation you are having in your project

While being able to add font files directly in theme and theme overrides is (slightly) more comfortable than having to create a DynamicFont, in Godot 4 we totally lost the ability to synchronize font settings through different nodes and node types.

Up to Godot 3.5.1, I used a DynamicFont - let's say small.tres, set my font file, and use it across all my nodes: labels, rtlabels, buttons, lineedits, textedits basically every type of node with text. Changing font_size in small.tres would reflect across the whole project.

Now DynamicFont is gone and you have to manually change theme_override_font_sizes/font_size for every single node in your project (with high risk of leaving some behind). The only exception being Label nodes thanks to the LabelSettings class.

But here's where Type Variations can come in handy.

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

When explaining how to use type variations, the documentation states that

You can select the base type there, which would typically be the name of a control node class (e.g., Button, Label, etc)

This leaves some room to assume that you can set Control as base type, and this is partially true. In fact, if you type "Control" in the base type selection menu and confirm, you won't be creating a new custom type called "Control" (as the given prompt says), but you'd be actually selecting Control, though it's not included in the list.

A type variation thus made will be available for all control-based, but won't show up in the dropdown menu and you'll have to type it manually in the selector, similarly to what happens if the theme is not set as project-wide.

Variations appear on the list only if the type variation belongs to the project-wide theme, which you can configure in the project settings. For any other case you have to input the name of the variation manually.

_{Side note: since the type variation selector is located right below the theme selector in the node inspector, I'd expect that if a theme is set, its type variations will show up as well, instead of project-wide ones only.}

As it was pointed out to me by @lewiji, this approach can replace the use I made of DynamicFonts. For example, you could create a "medium size" type with a certain font size. Updating it would reflect in every other control node "tagged" (as you'd do in HTML/CSS) with the medium size type variation, no matter if they are labels, lineedits, buttons. If they have text, they will update their font size accordingly.

That being said, I think that Control (or even Node) should be included in the base type list, so that this process feels more legit and control-based type variations can be picked up quickly in the dropdown menu.

Also, editing those type variations should make nodes update in real time as usual in the editor. To see changes, I have to run the scene (which is not always possible if the scene contains script dependancies) or restart the editor.

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

N/A

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

No

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

Self-explanatory

[YuriSizov]

Now DynamicFonts are gone and you have to manually change theme_override_font_sizes/font_size for every single node in your project (with high risk of letting some behind). The only exception being Label nodes thanks to the LabelSettings class.

Every node that has a font property also has a font size property. You don't need a variation for that.

Can't select Control as a base type in theme's type variations

Base Control doesn't have any theme properties, there is nothing to extend. I'd still say this is probably an oversight, but it's also not expected to be useful to anyone. What you attempt to do here is not how theme type variations are designed to work. You're supposed to extend node's base type, not use some generic variation on every node. So I cannot guarantee you that this would work without issues even if you manage to assign that type.

You also assume that every node has only one font and only one font size property, and they are always named the same. This is not guaranteed.

Also, editing those type variations should make nodes update in real time as usual in the editor. To see changes, I have to run the scene (which is not always possible if the scene contains script dependancies) or restart the editor.

They do. Maybe this has something to do with the fact that you are not using them in the supported way, not sure, since this was never tested.

[Overvault-64]

Every node that has a font property also has a font size property. You don't need a variation for that.

If I wanted to change their font size individually I could, quote myself, "manually change theme_override_font_sizes/font_size for every single node". I'm editing the title, maybe the rest of the issue overshadows the actual point of it, which is:

While being able to add font files directly in theme and theme overrides is (slightly) more comfortable than having to create a DynamicFont.tres, in Godot 4 we totally lost the ability to synchronize font settings through different nodes and node types.

If there's a solution for that, I'll be happy to stop misusing type variations.

They do (update in real time). Maybe this has something to do with the fact that you are not using them in the supported way, not sure, since this was never tested.

They don't, even if used in the supported way.

I have tested them in 3.5.1 and 4.0 beta10, and the editor just doesn't update until project reboot. I would not have written a single line of this issue without first doing all the relevant tests.

[YuriSizov]

If I wanted to change their font size individually I could, quote myself, "manually change theme_override_font_sizes/font_size for every single node". Maybe you missed this part

You misunderstood me. What I'm saying is that you can use the theme to set a particular default font and font size for every control type, and for the entire theme in general. You don't need to override it on individual controls, unless you want to change specific controls.

If I understand correctly, you were using local overrides for theme properties to share the same font resources, which allowed you to change the size in the same place. Yes, you can't do that anymore. For every place where you need to override the size, you need to do it manually, or through a custom solution. We currently don't have a way to share primitive types, same applies for colors for example which you also need to manually update everywhere where you do overrides.

They don't, even if used in the supported way.

Hmm, that should still work, but I admit I was thinking about a different workflow from your initial description. I have a couple of ideas where the issue might come from, but fixing it should have to wait for 4.1.

[Overvault-64]

If I understand correctly, you were using local overrides for theme properties to share the same font resources, which allowed you to change the size in the same place. Yes, you can't do that anymore.

Exactly, and it worked so well that I assumed it was intended. When I saw they were gone in Godot 4, I was like yo wtf, I need another solution, and that's when I was informed about the type variation thing.

For every place where you need to override the size, you need to do it manually

As I said, there is an exception, being LabelSettings, which basically allows you to do the trick. The class description itself encapsulates the philosophy:

Collection of common settings to customize label text.

That's the key. I've opened a thread about it, and this issue actually stemmed from it. It would be perfect if there was something like a "TextSettings" class, compatible with all the text-equipped nodes that would allow us to edit basic font settings at once across multiple nodes, as with LabelSettings, except it would also work across different node types and not Labels only.

[YuriSizov]

The problem is that we specifically moved the font size outside of the resource so you could override it quickly, without having to dupe the resource. It was usually a huge problem for users because of how unintuitive it was. So moving it back into a resource would result in reserving this usability improvement.

Now, I don't see why we couldn't have a base font size inside of the font resource and a dedicated font size property that would override that base size in resource, if present... I don't think we've considered something like that.

As for LabelSettings, we don't agree internally that it was a good solution. It duplicates the existing functionality instead of improving it, and splits the approach to solving the problem into multiple non-compatible paths. So I wouldn't consider anything similar in future.

---

Edit: In the meantime, you could use variations, but you'd need to make a variation for each base type that you want to have multiple font sizes. And that'll be harder to keep if you want to use variations for other adjustments as well. But, while that's more setup, it would allow you to change the sizes from the same, centralized location.

[Overvault-64]

a base font size inside of the font resource and a dedicated font size property that would override that base size in resource, if present

Sounds good

As for LabelSettings, we don't agree internally that it was a good solution

I find it easy to believe. I'm avoiding using it to reduce settings fragmentation

[Calinou]

Related to https://github.com/godotengine/godot-proposals/discussions/6074.

[Overvault-64]

I have tested them in 3.5.1 and 4.0 beta10, and the editor just doesn't update until project reboot.

From further tests, looks like this issue affects the project-wide theme in general, not only type variations. Also, changing scene tab in the editor is enough to apply the changes (no need to reload the project).

[YuriSizov]

Ah, yes, global themes don't report their changes well, because they are not directly related to the scene tree. Instead they are used as fallback values. I plan to fix that for 4.1 as well.

[Overvault-64]

hey @YuriSizov, news on this?

Now, I don't see why we couldn't have a base font size inside of the font resource and a dedicated font size property that would override that base size in resource, if present... I don't think we've considered something like that.

this would still be great

[YuriSizov]

No work has been done of it yet, sorry.

[Overvault-64]

No work has been done of it yet, sorry.

No worries, I'll comment here again in another 4-5 months if it doesn't bother you ahah thanks for your work

[Overvault-64]

Latest updates had the (I think collateral) effect of fixing some of the problems we discussed here. Just wanted to point them out.

Ah, yes, global themes don't report their changes well

Now they do.

editing type variations should make nodes update in real time as usual in the editor

What fixed the global themes issue above, also fixed this one I suppose.

Control should be included in the base type list, so that this process feels more legit

Now it's included and selectable. And yes, it feels legit now.

All these changes have definitely made my way of using type variations much more viable.

Only hiccup is the type variation selection menu not cooperating. According to the docs, if a theme is set as project-wide, its type variations should show up in the dropdown menu. This doesn't work for my Control-based variations, so it feels like there's something fixable underneath.

EDIT: While I was writing this, I double-tested selecting Control as base type and it didn't show up anymore. Weird.

[YuriSizov]

Yes, indeed, finally fixed global themes in 4.2. Glad you're enjoying the changes :)

While I was writing this, I double-tested selecting Control as base type and it didn't show up anymore. Weird.

I think someone reported this already, I vaguely remember this being discussed. Feel free to open issues though, it's not something that requires a proposal, but a fix.

[Overvault-64]

I'm closing this and reporting the remaining issues if they're not already there. Thank you @YuriSizov