Fix EditorTitleBar excessive width
https://github.com/user-attachments/assets/8113c691-19dc-42b6-aae9-5de3d632c9c4
Summary of Changes:
-
EditorScrollBox Extracted for Reuse:
-
- The EditorScrollBox (introduced in https://github.com/godotengine/godot/pull/97878) has been extracted into its own class to allow reuse across the editor. This helps address excessive width issues.
-
Improved Layout in EditorTitleBar:
-
- Refactored the layout using three expanding containers instead of relying on spacer size calculations. This simplifies alignment and makes future layout changes easier:
[ left_hb ] [ center_hb ] [ right_hb ]
- Refactored the layout using three expanding containers instead of relying on spacer size calculations. This simplifies alignment and makes future layout changes easier:
-
New Minimum Editor Size:
-
- The minimum size of the editor window is now set to 640×480. This change required adjusting many UI elements to fit within the new constraints. (Most of those adjustments are already done locally).
-
Selective Use of EditorScrollBox:
-
- The new EditorScrollBox has been applied to the main menus and screen buttons, but not to right_hb, which includes the EditorRunBar and plugin-specific controls. Note: it’s currently difficult to keep the main screen buttons centered when many plugins are added to the right container.
Requires testing on Android Editor to confirm compatibility and layout integrity on smaller screens.
-
Note: The change to the Renderer Button shown in the demo video is not included in this PR. That change is part of https://github.com/godotengine/godot/pull/109357, and is shown in the video only to demonstrate the final result when both PRs are merged.
-
Note: The Pause and Stop button changes shown in the video have been removed from this PR. They will be moved to a separate PR if needed.
For the main screen buttons, I was wondering if we shouldn't change them to TabBar/TabContainer, which would eventually allow to use main screen as a dock slot. Related: #106164
For main screen buttons (2D, 3D, ect.) this is 100% improvement (existing buttons will not break layout at editor minimum size and buttons added by plugins will not make it worse). Other changes I think require more discussion. In my opinion the end goal of all this changes (including https://github.com/godotengine/godot/pull/102301) is to fit editor on a quarter (at least) of the screen (fullhd monitor). For android - being able to use editor in portrait mode.
For the main screen buttons, I was wondering if we shouldn't change them to TabBar/TabContainer, which would eventually allow to use main screen as a dock slot. Related: #106164
I already have an old change that allows reparenting the TabBar of the TabContainer which may help with this, The only issue is that all the Main Screen plugins have a very large width due to their top bar minimum width which will make it harder to align two of them horizontally.
I already have some changes locally that can reduce their width and was thinking about reusing the new EditorScrollBar container introduced in this PR to move the select buttons to the left of the 2D/3D Editors like how they are done in Blender, I remember i have seen a feature request asking for that too.
For main screen buttons (2D, 3D, ect.) this is 100% improvement (existing buttons will not break layout at editor minimum size and buttons added by plugins will not make it worse). Other changes I think require more discussion. In my opinion the end goal of all this changes (including #102301) is to fit editor on a quarter (at least) of the screen (fullhd monitor). For android - being able to use editor in portrait mode.
- Yes the main goal is to support smaller screens for the editor to be able to increase the editor scale or tile the editor window without issues, and the only issue we have now are bottom panels and the main screen editor plugins that are preventing that, if we follow the same approach here https://github.com/godotengine/godot/pull/109361 by having a HFlowContainer with two children LeftHBoxContainer and RightHBoxContainer we can eliminate most of those issues in a clean way, and we will be left with the
EditorTitleBarpreventing that which this PR fixes and it can go with only reusing the new Container for main screen buttons only, and also we can optionally allow disabling the button's text in the EditorSettings like this.
This pretty much breaks editor title on macOS.
- Window name is no longer visible.
- Large portions of the title are not responding to drag.
- Tabs seems off center.
- Resizing is not quite uniform.
https://github.com/user-attachments/assets/b79e63e9-d802-4795-b629-b20389a11983
Title bar element alignment before the change, window name and all empty areas are draggable:
Some notes:
There's set_center_control method in the EditorTitleBar used with main_editor_button_hb to force center it regardless of other controls. Current implementation require a direct child of EditorTitleBar as argument, so it won't work when it wrapped in the new container, and it also depends on main_editor_button_hb being fixed size to work. Forced centering supposed to work only if there's plenty of free space on both sides, so it probably can be adjusted.
Window title can be added to the menu scroll container, since only one of two can be visible at the same time (menu bar still need to be in the scene tree, but will be zero size and invisible).
Window drag can be fixed by setting PASS mouse filter on all new containers.
- Window name is no longer visible.
I have applied a fix, please test again to confirm it.
- Large portions of the title are not responding to drag.
I have applied a fix, some containers was using mouse filter stop and changed them to pass, please confirm it.
- Tabs seems off center.
This is a result of reducing the editor size to 640x480, happens on all platforms because the main screen and bottom panels plugins still doesn't support the new size efficiently.
- Resizing is not quite uniform.
I gave the main screen buttons a higher stretch ratio on MACOS since there's no longer a menu. please check with EditorDebugger plugin for the best stretch ratio that fits MACOS.
Some notes:
There's
set_center_controlmethod in theEditorTitleBarused withmain_editor_button_hbto force center it regardless of other controls. Current implementation require a direct child ofEditorTitleBaras argument, so it won't work when it wrapped in the new container, and it also depends onmain_editor_button_hbbeing fixed size to work. Forced centering supposed to work only if there's plenty of free space on both sides, so it probably can be adjusted.Window title can be added to the menu scroll container, since only one of two can be visible at the same time (menu bar still need to be in the scene tree, but will be zero size and invisible).
Window drag can be fixed by setting PASS mouse filter on all new containers.
We may not need this anymore after this PR since it doesn't require the old ways of centering the main screen buttons and it's managed automatically by only using 3 containers and their expanding methods, the MainScreenButtons now have the higher expand ratio and is still affected by the EditorRunBar and the Renderer Button which are all part of the right hbox now.
It's not always 3 controls, there are extra spacers (left/right_menu_spacer) added on macOS to account for window buttons, these spacers are always different width, so this will introduce misalignment.
I'll retest it tomorrow.
I guess these extra spacers can be replaced by extra margins on side containers, these only exist to reserve empty space, actual window buttons are native elements and controlled/drawn by OS.
It's not always 3 controls, there are extra spacers (left/right_menu_spacer) added on macOS to account for window buttons, these spacers are always different width, so this will introduce misalignment.
Removed the right spacer since it's useless now after this change and moved the left spacer into the left HBox container is an internal child since it's only used for MACOS to show the title label, so they are now only 3 children for the EditorTitleBar.
Note: we also can add the label directly to the left hbox and we remove the left spacer too.
The new EditorScrollBox can't work with spacers since it doesn't have a minimum size and it needs to expand to fill the available space to be functional.
Also for testing i have used Zylan.EditorDebugger plugin to hide the CIE and the game editor top HFlowContainer because they was preventing resizing down the window.
Removed the right spacer since it's useles
It's not useless, if OS language is right-to-left and Godot language is left-to-right (or vice versa) buttons will be over the right spacer.
Dragging seems to work.
Title still not visible.
And main tabs still off center, it does not matter if there are a same number of controls on the both sides as long as spacers are different fixed size it will be off:
[ X - + ][ left container ][ center container ][ right container ][ ]
/\
center
[ X - + ][ left container ][ center container ][ right container ][ ] /\
center
It's so hard to access a mac and it will be great if you can help me by downloading EditorDebugger from asset store then enabling inspecting elements in the plugin and you inspect the title bar with F12 to be able to change the label or container settings in editor inspector to find a quick fix.
The reason why they are not centered is that they are no longer 3 containers, it should be like this to work on mac similar to other platforms.
[ left container ] [ center container ] [ right container ]
[ [ X - + ] scene-name - Godot ] [ 2D 3D Game Assets ] [ play buttons [ right spacer ] ]
Also for RTL layout i tested it and it works fine in all other platforms.
You can test it on non-mac too, I think you just have to remove the conditions here: https://github.com/godotengine/godot/blob/a3b42d85d27668f8992c0779ed3cc82d13db3dd9/editor/editor_node.cpp#L8117-L8127
You can test it on non-mac too
Not fully, you can enable extra spacers/title, and hide menu bar, but won't get native window buttons, so it would be hard to tell if something is wrong.
It's so hard to access a mac and it will be great if you can help me by downloading EditorDebugger
Will check it on Monday.
I did that in https://github.com/godotengine/godot/pull/105106#issuecomment-2784536122 and it was enough to see the problem.
You can test it on non-mac too, I think you just have to remove the conditions here:
Thanks, this helped test the project title label. It now uses a control parent, with its position and size manually adjusted so it can extend beyond the container limits and occupy all available space.
[ [ X - + ] ] [ 2D 3D Game Assets ] [ play buttons [ spacer ] ]
[ label ]
Title still not visible.
I’ve disabled the EditorHScrollBox for the main menu on macOS to ensure the label works properly, and I’m hoping it behaves the same as in the video without any issues.
LTR:
https://github.com/user-attachments/assets/36574583-80cf-4441-995f-9c32862c7733
RTL:
https://github.com/user-attachments/assets/f4e31d3e-48e8-4b8b-a468-ca6e99cc0cd1
One tiny fix to make title bar drag work:
diff --git a/editor/editor_node.cpp b/editor/editor_node.cpp
index 78e9ad85bb..84efce00e0 100644
--- a/editor/editor_node.cpp
+++ b/editor/editor_node.cpp
@@ -8193,6 +8193,7 @@ EditorNode::EditorNode() {
project_title->set_text_overrun_behavior(TextServer::OVERRUN_TRIM_ELLIPSIS);
project_title->set_mouse_filter(Control::MOUSE_FILTER_PASS);
project_title_control->add_child(project_title);
+ project_title_control->set_mouse_filter(Control::MOUSE_FILTER_PASS);
title_left_hbox->add_child(project_title_control, false, INTERNAL_MODE_BACK);
}
The rest looks and works fine on macOS.
There's still an issue with tiny window sizes, scroll containers seems to work only to some extent:
https://github.com/user-attachments/assets/b692197f-a466-41fe-ba23-3758c310f885
There's still an issue with tiny window sizes, scroll containers seems to work only to some extent:
The 2D/3D/Game/Script/Asset plugins prevents the window from being resized down, I'm using EditorDebugger plugin to hide The HFlowContainer that contains all those buttons for 2D and the ones in the Game window to test this PR.
I'm using EditorDebugger plugin to hide The HFlowContainer that contains all those buttons for 2D and Game editors to test this PR.
Yep, with the part hidden, it seems to resize fine all the way down.
These buttons are now completely hidden when not running the project, instead of just being disabled. They are only relevant during runtime and do not need to remain visible during regular editing.
That means that when running the project, they will still take space and make the title bar bigger. Hiding them doesn't really improve anything and only makes the play button annoyingly switch places. Unless you never run your project.
That means that when running the project, they will still take space and make the title bar bigger. Hiding them doesn't really improve anything and only makes the play button annoyingly switch places. Unless you never run your project.
I will move this to a new PR to be able to discuss it's usage.
That means that when running the project, they will still take space and make the title bar bigger. Hiding them doesn't really improve anything and only makes the play button annoyingly switch places. Unless you never run your project.
The play bar failed to keep the main screen buttons centered before this change, that's why i have made some contributions to avoid this issue.
Before (This caused parts of the editor to be off-screen):
After (Fixes the off-screen issue caused by the EditorTitleBar but not the main screen buttons centering issue):
Solutions (Hiding the pause and stop buttons while editing and removing the renderer button from the EditorTitleBar):
This helps to reduce the right container minimum width to keep the buttons centered but it doesn't solve the issue:
Needs rebase
This hasn't been rebased in a month, so this should probably be salvaged by another contributor. It's too late to merge for 4.6 but should be mergeable in the 4.7 dev cycle if it's updated.
#113051 would effectively replace it if it's merged (like what happened with bottom panel xd).