Improvements to SplitContainer including a drag bar background StyleBox

[Koyper]

Improves SplitContainer in a number of ways making it much easier to script, and tidies up the code as follows:

• A new split_bar_background StyleBox allows solid color, gradients or textures to fill in the split bar behind or in place of the grabber icon.
• An essential new property drag_area_scrollbar_offset is required if one of the child controls has a scrollbar or other selectable control up against the split bar, in order to prevent the drag area from blocking mouse selection of the scroll bar or control.
• New signals drag_started and drag_released make it easier to script saving and restoring the split_offset
• A new property dragging_enabled separates dragging from dragger_visibility so the appearance of the drag bar is independent from whether dragging is enabled or not.
• A new method get_drag_area_control returns the Control so buttons or any other type of Control can ride along with the split bar (see demo video below).
• New properties drag_area_margin_begin and drag_area_margin_end allow for scripting the long-axis size of the drag area and background, which makes some nice uses like drawers simple to script (see video below).
• A new drag_area_highlight_in_editor property allows you to see the drag area during development.

- A new virtual method _splits_ready() with a corresponding signal so a script knows when the split container children have been resized after the initial sort. This was a big problem because formerly, SplitContainer._ready() was called before the children had been fit to the container, and there was no easy way to get that information.

This PR also fixes this issue and adds the theme fix: #71862 and #71861

Adds this enhancement #61534

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.36.25.PM.mov

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

Here's the editor with the drag areas visible:

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

Production edit: Closes #61534, closes godotengine/godot-proposals#6230 and closes godotengine/godot-proposals#6231.

[YuriSizov]

That's a lot. It needs a proposal, or several, to explain various enhancements. Probably better done as several PRs too, but that would be more obvious after the proposals.

[Koyper]

Okay. I’ll put the proposal together and follow up as necessary.

…

On Feb 3, 2023, at 2:13 PM, Yuri Sizov ***@***.***> wrote: That's a lot. It needs a proposal, or several, to explain various enhancements. Probably better done as several PRs too, but that would be more obvious after the proposals. — Reply to this email directly, view it on GitHub <#72680 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIDFM5F5VVVVTRXIMFRQZWDWVVRG7ANCNFSM6AAAAAAUQR3F4M>. You are receiving this because you authored the thread.

[KoBeWi]

Needs rebase.

A new virtual method _splits_ready() with a corresponding signal so a script knows when the split container children have been resized after the initial sort.

You can also connect sort_children with CONNECT_DEFERRED and CONNECT_ONE_SHOT for the same result I think. Or ready with CONNECT_DEFERRED.

[Koyper]

You can also connect sort_children with CONNECT_DEFERRED and CONNECT_ONE_SHOT for the same result I think. Or ready with CONNECT_DEFERRED.

I just tried these, and sort_children emits too early, but ready with CONNECT_DEFERRED seems to work. The problem I was trying to solve invloves child Controls that are expensive to fit, which unpredictably cause SplitContainer `_ready()' to be called too early.

If there are still issues with the ready approach I will eventually know about it, so I could remove the proposed _splits_ready() and accompanying signal from the PR and put a new PR together later if an ugly head arises?

[KoBeWi]

If there are still issues with the ready approach I will eventually know about it, so I could remove the proposed _splits_ready() and accompanying signal from the PR and put a new PR together later if an ugly head arises?

Yeah right now the signal is not needed for anything. It's also inconsistent with other containers which don't expose anything like this.

[Koyper]

This push included a rebase and removed the _splits_ready() virtual method and related signal.

[KoBeWi]

An essential new property drag_area_scrollbar_offset is required if one of the child controls has a scrollbar or other selectable control up against the split bar, in order to prevent the drag area from blocking mouse selection of the scroll bar or control.

Can you show an example when this is useful? The child nodes of SplitContainer can't be shrunk past their minimum size, so it's impossible to overlap scrollbars and drag area.

New signals drag_started and drag_released make it easier to script saving and restoring the split_offset

Isn't dragged signal enough?

New properties drag_area_margin_begin and drag_area_margin_end allow for scripting the long-axis size of the drag area and background, which makes some nice uses like drawers simple to script (see video below).

Which video?

A new drag_area_show_drag_area property allows you to see the drag area during development.

Shouldn't this be editor-only? Also the double drag_area in name is awkward.

[Koyper]

@kitbdev All the changes we discussed were made - thanks for the excellent suggestions!

[akien-mga]

Sorry for the delay following up.
We're now in feature freeze for 4.3, so I'm moving this to the 4.4 milestone. My understanding is that it's ready to go otherwise, so we can merge early on in the 4.4 dev cycle. It will need a rebase to solve present merge conflicts.

[Koyper]

We're now in feature freeze for 4.3, so I'm moving this to the 4.4 milestone. My understanding is that it's ready to go otherwise, so we can merge early on in the 4.4 dev cycle. It will need a rebase to solve present merge conflicts.

Sounds good. I will take care of the conflicts shortly.

[Koyper]

In reference to #90411, there is quite a bit of overlapping effort (and similar thinking) in cleaning up SplitContainer, even before any additional features are implemented. Would it be easier to implement #90411 on top of this PR, since this PR addresses some more fundamental deficiencies? What is the sensible way to merge the efforts?

[akien-mga]

In reference to #90411, there is quite a bit of overlapping effort (and similar thinking) in cleaning up SplitContainer, even before any additional features are implemented. Would it be easier to implement #90411 on top of this PR, since this PR addresses some more fundamental deficiencies? What is the sensible way to merge the efforts?

CC @kitbdev

[kitbdev]

I don't think there is much overlap in cleaning up SplitContainer, besides some minor doc issues. #90411 just needs to touch a lot of things due to logic changes. Where they do clean up, they clean up different things like _get_sortable_child SortableVisbilityMode, #includes, or _get_separation().

#90411 needs some fixes to properly handle changing child visibility, so it isn't ready yet, and I don't want to hold up other PRs.
I don't mind rebasing on top of this. Though I would suggest some changes like moving draw back to the dragger.

[Koyper]

I don't think there is much overlap in cleaning up SplitContainer, besides some minor doc issues. #90411 just needs to touch a lot of things due to logic changes. Where they do clean up, they clean up different things like _get_sortable_child SortableVisbilityMode, #includes, or _get_separation().

#90411 needs some fixes to properly handle changing child visibility, so it isn't ready yet, and I don't want to hold up other PRs. I don't mind rebasing on top of this. Though I would suggest some changes like moving draw back to the dragger.

Thanks for offering to rebase on top of this. I did put the draw back into the dragger, and I see now why it needs to be there so you can have multiple dragger instances with more than two children. Each dragger now also saves its stylebox Rect2, so you should be able to keep an array of draggers and have them all update correctly. I believe the SortableVisbilityMode is also now there per a prior PR that hadn't yet been rebased here. Thanks for your comments, and I look forward to the multi-child improvements!

[kitbdev]

Looks good to me.

I still wish there was a better way to do the drag_area_highlight_in_editor than exposing it.

[akien-mga]

Thanks!