Add a new theme for the Android and XR editor

[m4gr3d]

• Add support for platform's customization of the editor theme
• Adds a new theme for the Android and XR editor based off @passivestar minimal theme

Note that I'm still iterating on the look and feel for the new theme, so feedback and contributions are welcomed!
To contribute, feel free to grab minimal_theme_high_ppi, make edits to it and submit back!

[dsnopek]

So, is the idea here that we can swap in a theme with less empty space on platforms (like Android) where you're likely to have less screen space?

[m4gr3d]

So, is the idea here that we can swap in a theme with less empty space on platforms (like Android) where you're likely to have less screen space?

I'm still iterating on the theme design and may end up going with two themes instead in order to satisfy different requirements:

• On Android and XR, if you're using the touchscreen / virtual touch instead of keyboard and mouse, you want the UI to be large enough for reliable interaction
• On the other hand, if you're using keyboard and mouse, then yes you probably want to maximize the content density, though this is mostly an issue for the Android editor since the XR editor can be resized at will.

[dsnopek]

Ok, thanks!

• On Android and XR, if you're using the touchscreen / virtual touch instead of keyboard and mouse, you want the UI to be large enough for reliable interaction

I worry about becoming too dependent on the theme for this point, though. If users can still select their own custom editor theme, we don't necessarily want them to lose the increased size for touch, right? Or, are we going to assume that if the user switches their editor theme on Android, it's on them to select a theme that's designed for touch?

[m4gr3d]

I worry about becoming too dependent on the theme for this point, though. If users can still select their own custom editor theme, we don't necessarily want them to lose the increased size for touch, right?

The functionality is not there yet, but we should be able to detect whether the user is using touch (whether virtual or physical) vs mouse and automatically update the target touch sizes to match. This could be placed behind a theme setting so that themes that are not designed for touch can still support touch interaction at the user's discretion.

I see this as a band-aid though because I expect themes not designed for touch to 'look' weird (and in the worst case not functional) when using this capability.

[m4gr3d]

Or, are we going to assume that if the user switches their editor theme on Android, it's on them to select a theme that's designed for touch?

That's my current assumption. The majority of users (for any piece of software) stick to the default settings, so the expectation is that those that are switching are aware of the trade-offs.
If the touchscreen-optimized theme approach is successful though, we can apply the same approach to the other themes / provide guidelines for theme designer so users have options.

[m4gr3d]

Note that I'm still iterating on the look and feel for the new theme, so feedback and contributions are welcomed!
To contribute, feel free to grab minimal_theme_high_ppi, make edits to it and submit back!

[passivestar]

provide guidelines for theme designer so users have options

Godot has spacing presets in editor settings, it would be a better solution if themes could make use of them rather than having to hard-code values. Not just for space, but for other variables defined in editor settings as well.

I currently support low/high editor scale by manually editing the second .tres file, but users have been asking me to make a light theme. If I were to do that I'd need to maintain 4 theme files, 2 for each color scheme.

If I also wanted to support touch screens in the minimal theme by providing an option with larger buttons and larger paddings I'd need to maintain 8 theme files. And so on.

This is fundamentally a problem with the engine theming system to solve. Not for theme designers

[syntaxerror247]

Android editor needs a complete UI overhaul and I believe, most important change would be to make editor UI dialogs like scene_tree or inspector floating. It should also have a title bar, by clicking on it we should be able to expand or contract it and this same title bar will be used to move the dialog. This can solve the issues with less screen space.

I haven't looked at implementation yet but this is in my TODO list. Can't promise, but would try to do before v4.4.
It would be okay though, if someone takes the initiative to do it, as I am not sure I will be able to start working on it anytime soon.

[m4gr3d]

provide guidelines for theme designer so users have options

Godot has spacing presets in editor settings, it would be a better solution if themes could make use of them rather than having to hard-code values. Not just for space, but for other variables defined in editor settings as well.

I currently support low/high editor scale by manually editing the second .tres file, but users have been asking me to make a light theme. If I were to do that I'd need to maintain 4 theme files, 2 for each color scheme.

If I also wanted to support touch screens in the minimal theme by providing an option with larger buttons and larger paddings I'd need to maintain 8 theme files. And so on.

This is fundamentally a problem with the engine theming system to solve. Not for theme designers

@passivestar Do you have a list of what, from your perspective, is missing that would help improve the engine theming capabilities?

[m4gr3d]

Android editor needs a complete UI overhaul and I believe, most important change would be to make editor UI dialogs like scene_tree or inspector floating. It should also have a title bar, by clicking on it we should be able to expand or contract it and this same title bar will be used to move the dialog. This can solve the issues with less screen space.

I haven't looked at implementation yet but this is in my TODO list. Can't promise, but would try to do before v4.4. It would be okay though, if someone takes the initiative to do it, as I am not sure I will be able to start working on it anytime soon.

@syntaxerror247 Great to hear you're also looking into how to update the Android editor UI! This is something I've been looking to do for quite some time, but to your point, it's a large task.
It may be worth drafting a proposal so we can align on how to break down the task in smaller manageable chunks. Updating the theme to be more touch friendly is what I had in mind as a starting step, but there is much more that can be done!

[passivestar]

@passivestar Do you have a list of what, from your perspective, is missing that would help improve the engine theming capabilities?

It could help to look at the default theme code to see what kind of things it does to generate the default theme

Off the top of my head:

1. Access to editor settings. You need to be able to access space settings, editor scale, colors, border radius, etc
2. Expressions. You need to be able to do simple math on those variables, lighten/darken colors, maybe reference values from other properties of your own theme
3. Some kind of node addressing system would be nice, it doesn't need to be as flexible as CSS selectors but it would help to have at least some way to query nodes based on their position in the hierarchy to not need to hardcode type variants into godot codebase (this is optional but nice to have)

A good criteria for the theming system imo would be to have a system that would allow to convert the default theme from C++ into a resource

[akien-mga]

I haven't reviewed nor tested, but I just want to flag this early: While I'm fine introducing platform-specific theme variations, I am wary of this being used as a way to introduce a wholly different theme just for one platform when that theme is something that could or should be considered for all platforms.

It's an easy way to sidestep the inevitable bikeshedding that would come with trying to change the default theme, but I don't think we should introduce a precedent where one platform just goes with its own custom theme without a holistic assessment.

To be clear I'm not saying this is a bad change - and it's fine to keep working on it. I just want to flag this to make sure we have the Theme Discussion™ before unilaterally introducing a new default theme to some platforms. The default theme is part of the brand identity of Godot and not something we should change lightly. (Also to be clear I love passivestar's theme and consider it a good candidate for a new default theme if we decided to change it - but again that's a bigger discussion that needs to happen.)

Making a variation of some metrics (margins, etc.) of the current default theme on some platforms would totally be fine of course, like we already do with e.g. scrollbars for touchscreens.

[etodanik]

I haven't reviewed nor tested, but I just want to flag this early: While I'm fine introducing platform-specific theme variations, I am wary of this being used as a way to introduce a wholly different theme just for one platform when that theme is something that could or should be considered for all platforms.

It's an easy way to sidestep the inevitable bikeshedding that would come with trying to change the default theme, but I don't think we should introduce a precedent where one platform just goes with its own custom theme without a holistic assessment.

To be clear I'm not saying this is a bad change - and it's fine to keep working on it. I just want to flag this to make sure we have the Theme Discussion™ before unilaterally introducing a new default theme to some platforms. The default theme is part of the brand identity of Godot and not something we should change lightly. (Also to be clear I love passivestar's theme and consider it a good candidate for a new default theme if we decided to change it - but again that's a bigger discussion that needs to happen.)

Making a variation of some metrics (margins, etc.) of the current default theme on some platforms would totally be fine of course, like we already do with e.g. scrollbars for touchscreens.

Just to voice it out, I think the default theme for Godot being its’ brand identity is true but in a much less flattering way than some of the maintainers think.

It’s more so a brand identity in a way of anchoring Godot to a perceived “this is not a serious tool “ past.

passivestar’s theme is popular because it takes eyes off Godot and puts the center of attention on the content, as most professional tools UI do.

Projects such as Blender or GIMP also went through similar birthing pains where quirky brand identities had to be minimized for the tool to become more of a professional tool and need less “standing out” brand identity wise.