Make editor's dock gaps and trees line heights configurable in editor settings

[passivestar]

Describe the project you are working on

Any game

Describe the problem or limitation you are having in your project

Not that many things fit on screen

Games by their nature require you to work with a lot of files and objects. Being able to fit more of them on screen will make life easier as it will be easier to find things in your project

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

Default theme on the left, reduced line heights and reduced dock gaps on the right:

I want to emphasize that this proposal is NOT about changing anything in the default theme, only making those things configurable!

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

Editor Settings -> Interface -> Theme could have 2 new sliders:

• Dock gaps
• Tree view line height

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

You can make your own editor theme to override those setings, as I did in the screenshot above, but I want to point out that this is a usability issue, not an aesthetics issue. Making those things customizable without requiring a custom theme will make the editor more accessible to people with different screen sizes who want to dive into Godot

For existing users it will make lives easier too because we won't need to bother with custom themes for something this essential

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

Basic accessibility feature

[Calinou]

• Related to Decrease margins around the editor and project manager windows godot#40287
  and Engine UX/UI redesign (Mock-up) #8264 (comment).

For PopupMenu/ItemList/Tree line height, we can allow the existing Additional Spacing setting to be negative, but it has some caveats as mentioned in the comment linked above.

[Koalamana9]

window_border_margin and top_bar_separation should also be editable in the editor, at the moment these constants are hardcoded to 8

[YuriSizov]

window_border_margin and top_bar_separation should also be editable in the editor, at the moment these constants are hardcoded to 8

They are not hardcoded, you can create and use a custom editor theme that changes them. I don't think it's a good idea to expose absolutely every parameter of the theme in the general editor settings. If you want to go deep, there is already an option for that.

[grossqx]

It would be sweet to have access to this without a custom theme.

[AThousandShips]

That could be said for any number of properties, I don't see why this one specifically is special enough to warrant this

[Koalamana9]

expose absolutely every parameter

This proposal suggests adding only two parameters, if mine included it's a total of four, which is quite far from your absolutely everything

[AThousandShips]

Okay that's not the point

Why these and not others? I'm sure people might like to change any number of theme details conveniently, please have some perspective 🙂

[grossqx]

Okay that's not the point

Why these and not others? I'm sure people might like to change any number of theme details conveniently, please have some perspective 🙂

Imho, looking at the options that are already exposed in the proposed menu, having those two besides them doesn't seem illogical at all. Whether or not any other parameters should be considered too is a valid question.

[AThousandShips]

And I ask again: why these specifically?

Why not any number of others?

So far all the argument I see is "it'd be nice", please provide reasons why this property in particular is so common to modify that it justifies cluttering this menu further

The whole point is that we can't just put everything in there so some support for why is needed, what is the reason it's too inconvenient to make a theme instead if you need it

Because the answer to "why can't we put it there" is "we can't put anything there unless there's a good reason"

[grossqx]

And I ask again: why these specifically?

Why not any number of others?

So far all the argument I see is "it'd be nice", please provide reasons why this property in particular is so common to modify that it justifies cluttering this menu further

The whole point is that we can't just put everything in there so some support for why is needed, what is the reason it's too inconvenient to make a theme instead if you need it

Because the answer to "why can't we put it there" is "we can't put anything there unless there's a good reason"

It is much more useful to have it there than for example border width or radius. So whatever reason was used to expose those should work here too. If cluttering is a problem, maybe some of those can be hidden. I've never been a person to care about or edit themes, but having more items fit on screen can be useful for some displays and has almost the same usefulness as font size, which is of course exposed in editor settings. Creating a custom theme is just a bit deeper than most people usually go about UI customization.

[passivestar]

An argument could be made for packaging all of those "compactifying" changes into a theme, shipping that theme with godot and exposing it in editor settings via a dropdown. In that case you could probably also have other themes, not only for accessibility reasons. But that's a bigger change than this proposal

I'm not sure if the window border margin or top bar separation are nearly as big of a problem as space between tree items and dock gaps, and I agree that fewer options in there is better. On that note I think some stuff could actually be removed from there, like that "Relationship Line Opacity", seems like a random thing to expose

[passivestar]

@jmarceno my only concern about custom themes is that they may need maintenance, and I'd like to still be able to use the editor on my small laptop screen when I update to Godot 4.3, 4.4. 5.0, etc. Which is why I think it's important to recognize which settings are crucial for accessibility

[reduz]

This is a specific topic that is brought up time and time again by users for years, so I agree that it should be an editor setting instead of forcing to go through a theme. Seems a significant amount of people really prefer to customize their margins, so I am no one to judge or impede this.

[Dan-Mizu]

As I understand it the issue is using the editor on smaller (or larger) screens.

Instead of an additional editor setting, can this be handled in the same way that code font size is handled? Currently, when using CTRL +/CTRL - it seems to only affect the font size of the text inside the script window (Code Font Size in Editor settings) instead of the font size of the entire editor (Main Font Size). As a newcomer to Godot, that was a bit jarring to me. When using VSCode for example, I just use the CTRL +/CTRL - hotkeys to make the entire editor smaller/larger- not just the code. When i switch between devices with different screen sizes this is the first thing I do every time and takes just a couple key strokes. Using the CTRL +/CTRL - hotkey to make your current window match your current screen size seems to be universal across programs. This route doesn't require an entirely separate new setting while still being device independent and feeling natural.

I get that its not the same thing as line spacing but it effectively solves the original problem. Perhaps have the zooming in/out hotkey apply to the entirety of the editor instead of just the script window for quicker, more intuitive, and accessible sizing changes and keep more granular settings like line height within themes?

[Calinou]

Perhaps have the zooming in/out hotkey apply to the entirety of the editor instead of just the script window for quicker, more intuitive, and accessible sizing changes and keep more granular settings like line height within themes?

Runtime editor scale changes aren't supported yet. It would be possible to support them by piggybacking on the 2D scale factor system instead of regenerating the editor them every time the editor scale is changed, but this would result in icons looking blurry (unless we choose to always generate them at a 2× scale factor in case the user changes the editor scale later on).

Either way, this is a separate issue – reducing spacing makes it possible to increase the available screen real estate without compromising on text or icon size, which is important for accessibility.

[Dan-Mizu]

Runtime editor scale changes aren't supported yet. It would be possible to support them by piggybacking on the 2D scale factor system instead of regenerating the editor them every time the editor scale is changed, but this would result in icons looking blurry (unless we choose to always generate them at a 2× scale factor in case the user changes the editor scale later on).

Yea I see what you mean now as I change the Main Font Size setting in Godot. Text size changes but icon sizes do not.

I was trying to draw parallels with other programs in the same vein and how they handle accessibility options: https://code.visualstudio.com/docs/editor/accessibility

But VSCode's icon sizes also change with zoom level. VSCode also seems to have a line height setting in its editor settings- but I don't believe this is manipulated with the zoom level.

I wasn't proposing scale changes, rather switch the CTRL +/CTRL - shortcut to affect the "Main Font Size" setting rather than just "Code Font Size", but without it also affecting the icon sizing it may not be a full solution to the issue of being able to match program size to device screen real estate quickly and naturally.

[Calinou]

I wasn't proposing scale changes, rather switch the CTRL +/CTRL - shortcut to affect the "Main Font Size" setting rather than just "Code Font Size",

Ctrl + Mouse wheel should only affect the currently zoomed on control, not the entire editor. This also applies to the keyboard equivalents Ctrl + + and Ctrl + -.

If you want shortcuts to adjust the entire editor scale, this should be a separate set of shortcuts as it serves different use cases.

[Dan-Mizu]

Ctrl + Mouse wheel should only affect the currently zoomed on control, not the entire editor. This also applies to the keyboard equivalents Ctrl + + and Ctrl + -.

Sure, but it doesn't currently do that. It only currently works on the script editing view- and all it does is change the "Code Font Size" editor setting. There should be parity with other apps by applying changes to "Main Font Size" when using the shortcut anywhere else in the editor. When i first started using Godot i tried the shortcut on the editor and just thought it wasn't implemented until I tried it on the script view, as it was something I was used to using with VSCode/code editing apps, browser apps, adobe apps etc.

[Calinou]

When i first started using Godot i tried the shortcut on the editor and just thought it wasn't implemented until I tried it on the script view, as it was something I was used to using with VSCode/code editing apps, browser apps, adobe apps etc.

Ctrl + Mouse wheel doesn't change the font size of the UI in any of the apps you mentioned. It changes the zoom factor of the main view when performed on the main view, but it doesn't make text located outside the main view larger or smaller.

[Dan-Mizu]

Perhaps not in browsers, but at least in VSCode (CTRL+/-, Ctrl + Mouse wheel isnt a hotkey in VSCode) it does change the font size for both the workspace/explorer view as well as the toolbar.

Nevertheless, Godot could use an entire accessibility-focused feature update which could address this and many other concerns (like issues with the dots being hard to discern on the skeleton re-targeting system for those with red/green colorblindness).

[akien-mga]

Implemented by godotengine/godot#87085.