Add SizeContainer

[StarryWorm]

• Closes Add a SizeContainer control node godot-proposals#8333
• Supersedes/Implementes internally Add a custom_maximum_size to Control godot-proposals#13534
• Supersedes Implement a new property named ScrollContainer.max_size #94171
• Includes the fix in Fix Control::_update_minimum_size() not updating offsets #112525 (Noted such that if that PR causes any issues, the fix to said issues gets ported here)

Adds a custom_maximum_size internal property to Control. The maximum_size will serve as a cap on the container's size.

The custom_maximum_size is a Size2, and will apply dimension-wise if that dimension's value is greater than 0.

• e.g. custom_maximum_size= (100,0) will cap the width to 100 but will not cap the height

~

Adds a SizeContainer which exposes the custom_maximum_size property. This container will also apply this property to all of its children Controls.
If a child has the Expand size flag, the container will expand to its maximum size in the specified axis.
Cannot have specific anchor flags, which would cause it to expand to be larger than its designated maximum size (namely, all of the Wide types and the Full Rect). This can technically still be overridden by using Custom anchoring, but that's A. beyond my control, B. an advanced-user thing -- use it at your own risk.

Additional feature:

• A ScrollContainer with a custom_maximum_size (i.e. within a SizeContainer) will first expand as much as it can until it reaches the maximum size, and then will start showing scrollbars as needed.

Future work:

• Expose the horizontal component of custom_maximum_size in Label as autowrap_width, implementing Add autowrap_maximum_width to Label and RichTextLabel godot-proposals#13568

[StarryWorm]

The icon SVG currently is a simple copy of MarginContainer's. I am not good at graphic design, and would like to request that whoever has handled this in the past please contribute an appropriate icon.
I don't know who that is, but ATS (or whichever other maintainer sees this), please cc the correct person for me, thanks!

[scgm0]

Can this new node enable the ScrollContainer to start scrolling when its size reaches max, otherwise, the ScrollContainer expands normally in size?

[KoBeWi]

So how is it better than #94171?
You can set ScrollContainer's max size, make scrollbars invisible, and you will get effectively the same thing.

[StarryWorm]

So how is it better than #94171?
You can set ScrollContainer's max size, make scrollbars invisible, and you will get effectively the same thing.

Because that is giving ScrollContainer the responsibility of limiting size, and necessitates a workaround - making invisible scrollbars - to achieve the same effect.
Just like every other subtype of Container does one thing, ScrollContainer should do its one thing, namely scrolling, and this SizeContainer would do its one thing, namely limiting size.

Can this new node enable the ScrollContainer to start scrolling when its size reaches max, otherwise, the ScrollContainer expands normally in size?

It should. If it doesn't, then there's an implementation issue. WIll try it, and fix if it doesn't work.

[StarryWorm]

Added support for ScrollContainer. This required a bit more of an involved change since there was no existing way to get the "maximum size" a Control could fill. I put it as the get_combined_minimum_size() by default and then provided a specific override for ScrollContainer. I don't think any of the other Control types need/support something like that but I might be wrong.

Edit: maybe this could be used for autowrap with Labels, will investigate

[StarryWorm]

@KoBeWi I saw your comment on the proposal, godotengine/godot-proposals#13534 (comment). Discussing here since it is implementation-level, not feature discussion.

Could you please give more details on what you are suggesting for the implementation, so that we can discuss it, and I can maybe work towards migrating the implementation to it?

The current get_combined_maximum_size() approach is quite nice, in my opinion, since it doesn't touch any existing code, meaning 0 risk of compatibility breakage, but I am completely open to anything that would be better than it.

[KoBeWi]

It would be like #94171 and godotengine/godot-proposals#13568, except instead of an exposed property in the relevant node, the max size would be set by SizeContainer.

That means Control would get custom_maximum_size that can be used internally by derived nodes, but the property itself would not be available to the user. It's a weird design, but it would allow SizeContainer to be more functional.

[StarryWorm]

How would that be any better than the get_combined_maximum_size() approach the PR currently employs?

Sidenote: The way #94171 was implemented wouldn't have worked for what this PR is trying to accomplish. It would only be a limit on the largest_child_min_size which isn't the expand-until-maximum-size-reached design this PR adds (and what people seem to be wanting).

[KoBeWi]

How can I achieve growing ScrollContainer?
I have this structure:

When I duplicate TextureRect, it adds more columns, but the ScrollContainer keeps its size and instead ScrollBar appears immediately. Am I doing something wrong?

How would that be any better than the get_combined_maximum_size() approach the PR currently employs?

tbh I missed when you changed it. That approach makes sense.

[StarryWorm]

That's weird, I have that exact same setup (well a VBox instead of HBox) and it works with the latest version of the PR. Does your size container have a maximum_size set?

Edit: It shouldn't matter, I checked the code (I don't have access to my machine which has the binary at the moment), and maximum_size only acts as an upper bound if defined, if not defined it will just expand to infinity.

[KoBeWi]

I'm using the latest version and I do have maximum size set. Can you share your scene?

[StarryWorm]

Sure, here's my file https://drive.google.com/file/d/1wign3IAbZnfNcwUqaYeuQMVXofzEbmgo/view?usp=drive_link
The setup is the same as yours

Edit: please send yours, so I can compare both on my device and make it work for you scenario - provided it is proper use of the Container

[KoBeWi]

I found the difference. My ScrollContainer had vertical_scroll_mode set to Auto. I noticed your ScrollContainer has horizontal_scroll_mode disabled, so I did that (for vertical) and it works. It's weird though, why is orthogonal scroll mode relevant, if the container grows in a different direction?

[StarryWorm]

Well, that's definitely unintended behavior. I'll take a look at why it's happening.

Edit: I had it disabled because getting the horizontal scrollbar was annoying me, which thinking about it, it shouldn't have showed up in the first place :/

[StarryWorm]

Revamped implementation:

This now uses a custom_maximum_size property at the Control level, which mirrors the custom_minimum_size property. The only difference is that it is not visible in the Editor for all Control types; SizeContainer makes it visible.
SizeContainer will also set the value for its children.

This now supports ScrollContainer properly, as well as reacting to any and all relevant changes in Editor (change size flags, change maximum size, etc).

I've split it into two commits because the changes in both are significant enough to warrant separate commits.
The first commit is very noisy because of the depreciation of the minimum size change-related methods and signals being deprecated in favor of new size bounds change versions. Everything is maintained under the DISABLE_DEPRECATED definition to avoid breaking compatibility.

• Note: If any other PRs get merged before this one does that call any of the deprecated methods, this PR will need updating, or the Linux disable-everything CI run will fail at compilation time.