Use HFlowContainers for toolbars to allow for smaller resizing of the MainScreen element

[nyxkn]

Describe the project you are working on

This aims to solve an editor limitation, regardless of the type of project.

Describe the problem or limitation you are having in your project

The godot editor window cannot be horizontally resized to small sizes. When it reaches a small enough width, the content of the editor starts clipping and becomes inaccessible.

For example:

This is on a 1920x1080 screen, with Godot resized to exactly half the width of the screen. The right-most part of the inspector tab is clipped. The central MainScreen cannot be resized to a smaller size (in an attempt to bring the inspector back into the window).

This behaviour is frustrating, and instead I'd like to be able to still see and access everything, even if I have to sacrifice real estate of the main screen.
I think this is an issue that's most likely to come up when using tiled window managers, and most notably when one tries to have two godot windows side by side, e.g. for copying stuff between projects or when referencing another project.

The same issue was raised in #4845. The toolbars are the main culprit and using HFlowContainers instead of HBoxes seems like a good compromise to me.

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

Allow the central MainScreen control to be resized to a smaller width.

That way we can make use of a much smaller total editor width, while everything remains accessible instead of clipped.

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

The main culprit for the inability to resize this node are the horizontal toolbars. The main one at the top with all the buttons, just below the open files tab, and the one at the very bottom ("Output, Debugger..."). These use an HBoxContainer, which cannot be resized to be smaller than the total width of the children.

By replacing the HBox with an HFlowContainer we can allow the toolbars to be resized smaller.

Example:

The godot editor still takes half the screen width, but now the toolbars are wrapping on a new row and the inspector becomes accessible.

Now I can also fit two godot windows in the same 1920px screen side by side, which is helpful when copying stuff between projects:

EDIT: And this is possibly even more relevant now that the script window can be floated:

I have proof-of-concept code for this on my fork: https://github.com/nyxkn/godot/tree/flow-resize
It needs some cleanup but I'm happy to do that and open a PR in case there is interest in this proposal. Also happy to work on this problem through other angles if suggested.

I also remove the minimum_size of 170px for the dock elements and the 200px minimum size from the tabcontainer of the script editor. The latter is necessary to resize the script view, but the docks change makes less of an improvement and potentially not needed.

Here is a video of the resizing in action. The toolbars are automatically reflowed into multiple rows, saving horizontal space.

flow-resize-demo-2.mp4

At the smallest, when toolbars have many rows, it doesn't look the prettiest, but everything is still accessible, which is probably a nicer solution than to let some of the content be clipped.

I'll note one issue with this approach: I had to remove the spacers in the script toolbar because they're only available for hboxes. But the same spacer layout can maybe be achieved in other ways with the hflowcontainer.

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

I think an editor plugin could be used to remove some of the minimum_size constraints set on a few things, namely the dock elements and the open files tabcontainer, but it might not be able to replace the hboxes with hflows.

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

This seems to need to be a core modification.

[Calinou]

• Related to Replace contextual toolbars with contextual drawers #3550 and Implement an inspector "Action Area" #4273.

I remember this being attempted in the past, and there were some blockers that made it not worthwhile for now. I don't remember what exactly was the problem though.

[nyxkn]

Thanks for the reply!

One issue I've come across so far with this approach is that the extra controls that get dynamically added onto the top toolbar (like for example the ControlEditorToolbar), get floated to the far right, because the HFlow is set to expand.

[kitbdev]

The bottom dock could be converted into a TabBar instead of using buttons, so it has functionality like the other docks including resizing down. This way it also doesn't take up more vertical space.

[Musclorman]

--Google translate--
Ok. So it would come from the wingets used if I understood correctly. I think that if godot is compatible with tiny screens then for tablets and PCs in portrait and with other software open next to it it would also be beneficial. Then if godot works on a VGA screen then it can work on a larger screen without problems (some smartphones in 800x320 for example).
Have a nice day.
--Original French text--
Ok. Donc ca viendrait des winget utilisés si j'ai bien compris. Je panse que si godot est compatible avec des écrans minuscules alors pour les tablettes et les PC en portrait et avec d'autres logiciels ouverts a coté ce serait aussi bénéfique. Puis si godot marche sur un ecran VGA alors il peu marcher sur un ecran plus grand sans problèmes (certains smartphones en 800x320 par exemple).
Bonne journée.

[WhalesState]

We can move the mouse modes to a new side panel similar to blender, they are 8 buttons.

Alternatively, using an OptionButton for mouse modes would also solve this, as only one can be selected at a time.