Unify theme item lookup in Controls and respect default font #55497
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Okay, let's try this. This is
3.x
only. Fixes #36614.The problem was that the default font defined on any theme is never respected when looking up theme items from controls. The only way to receive the default font is to either directly fetch it from the Theme or to ask that Theme for an item that doesn't exist without checking with
has_...
first. This means that you can never, realistically, hit it for controls automatically. And that means, you can never get it from the custom project theme.Now, this change is a fix for this behavior, and it matches the behavior currently present in
master
(added in #41100). This fix means that if any theme in the lookup chain has a default font, it will be used (as fallback), and no further lookup will be performed. This breaks current behavior, but I don't think that the impact of that change outweighs the benefit. In fact, since the default font never worked as expected, I doubt anyone actually used it. So I think this change is justified for3.5
.While at it I've also unified the theme item lookup to match what we have in
master
. This can probably fix a few issues as well, since the old behavior was arbitrary for each theme item type. I excluded shaders from this change, since they are already deprecated and I don't want to add a shader type to theDataType
enum and possibly create problems for the theme editor and other stuff.This change is rather exciting, as it lays the groundwork for a backport of theme type variations (#50169). If this is accepted, theme type variations can be added without any compatibility breakage and can be a very cool feature for 3.5.