Fix EditorTitleBar excessive width

[WhalesState]

Screencast.From.2025-08-07.20-20-24.mp4

Summary of Changes:

• Pause and Stop Buttons Hidden (Not Disabled):

• • 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. (This is in a separate commit to allow moving it to a different PR if needed.)

• EditorScrollBox Extracted for Reuse:

• • The EditorScrollBox (introduced in Fix BottomPanel excessive width. #97878) has been extracted into its own class to allow reuse across the editor. This helps address excessive width/height issues and enables its use in EditorPlugin UIs.

• 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 ]

• 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 Use renderer icons instead of text to reduce the topbar width. #109357, and is shown in the video only to demonstrate the final result when both PRs are merged.

[KoBeWi]

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

[arkology]

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.

[WhalesState]

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.

[WhalesState]

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 Improve and reduce animation player/track editor width. #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 EditorTitleBar preventing 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.

[WhalesState]

I have made a change to the method to defer the call internally, but i forgot to update the docs. It should work fine without this Note.

void EditorScrollBox::ensure_control_visible(Control *p_control) {
	ERR_FAIL_NULL(p_control);
	if (scroll_container->is_ancestor_of(p_control)) {
		callable_mp(scroll_container, &ScrollContainer::ensure_control_visible).call_deferred(p_control);
	}
}

[bruvzg]

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.

Screen.Recording.2025-08-07.at.22.44.00.mov

Title bar element alignment before the change, window name and all empty areas are draggable:

[bruvzg]

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.

[WhalesState]

• 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.

[WhalesState]

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.

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.

[bruvzg]

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.

[bruvzg]

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.

[WhalesState]

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.