Improve SplitContainer grab area by adding margin properties and exposing the Control to scripting

[Koyper]

Describe the project you are working on

GUI elements for handling large collections of items, and GUI elements for organizing related containers of text, lists and collections - common GUI utility used frequently.

Describe the problem or limitation you are having in your project

Because you can't access the grab area Control, and there is no way to modify the span of the split bar accross the SplitContainer, a lot of ungainly scripting code is required to implement a few highly useful variations of SplitContainers.

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

• A common gui implementation includes buttons on the split bar dividing two container areas. This is typically used to move assets back and forth between related collections. Exposing the Control used by the new grab area in SplitContainer, makes adding buttons to the split bar a matter of a few lines of code.
• The span of the split bar is currently fixed to the entire width of the SplitContainer. By simply providing drag_area_margin_begin and drag_area_margin_end properties, useful combinations of SplitContainers can be created with a few lines of code, such as "drawers" that collapse against at the top, bottom or side of a parent container.

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

The code is complete per PR #72680

The PR combines this proposal with proposal #6230, with fixes various issues with SplitContainer that make scripting difficult.

Screen.Recording.2023-02-03.at.12.29.31.PM.mov

This is all the GDScript neccessary for the buttons:

func _ready():
	var button := $Button
	var button_right := $ButtonRight
	remove_child(button)
	remove_child(button_right)
	hsplit.get_drag_area_control().add_child(button)
	hsplit.get_drag_area_control().add_child(button_right)
	button.position.y = -150 
	button_right.position.y = -50

Screen.Recording.2023-02-03.at.12.40.10.PM.mov

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

Extremely difficult to implement in script - all of the visual split bar elements have to be drawn over a split container with dragging disabled, and the script has to set the offset when the overlaid control is dragged.

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

These two enhancements are small modifications to split_container.cpp, but greatly improve it's utility.

[domportera]

I'm not sure if your feedback and contribution here addresses this, but I agree that splits need to expose more of their dragging area stuff to scripting. currently trying to implement a pull-down drawer on mobile, and it's virtually impossible with the world's smallest drag touch area at the top of the screen. simple access to that control would help immensely

[Koyper]

I'm not sure if your feedback and contribution here addresses this, but I agree that splits need to expose more of their dragging area stuff to scripting. currently trying to implement a pull-down drawer on mobile, and it's virtually impossible with the world's smallest drag touch area at the top of the screen. simple access to that control would help immensely

If you can describe a little more detail about what you're trying to do, I can tell you if the PR can help - it's intended to address all of the deficiencies in the split container.

[domportera]

If you can describe a little more detail about what you're trying to do, I can tell you if the PR can help - it's intended to address all of the deficiencies in the split container.

Basically, it would be great to be able to define the width of a split's drag handle (possibly even separately from how it's rendered) because it is a nightmare trying to manipulate a split container on a phone. touch controls are pretty inaccurate so it would be nice to be able to give fat fingers like my own a chance at grabbing one of these bad boys

[Koyper]

There’s a new theme constant in Godot 4, even without this PR, that gives you a grab area separate from the split width. If you are able to try out Godot 4, you’ll be able to experiment with it. This PR proposes the ability to offset that grab area, but you might not need that for your project. Hope this helps.

[domportera]

ah thanks, i did not know that. unfortunately im stuck with Godot 3 because of C# android support, but then i will wait patiently

[Koyper]

There’s a Godot 4 build for C# - see the latest beta news item.

[domportera]

yes I know there is and I'd jump on the opportunity to upgrade but unfortunately it seems that Android is currently an unsupported build target with C# (possibly due to issues upstream) /: