Allow SplitContainer to have a grab area larger than its visual grabber

[groud]

Sometimes in a SplitContainer, you would want a thin visible grabber, or possibly no visible grabber image at all (for a borderless split). But with the current implementation, the grabbing area is dependent on the texture width and the "sep" theme variable, so with no texture and a "sep" of zero, the grabbing area becomes too thin and thus hard/impossible to grab.

This PR allows you, via a theme constant, to have a grabbing area width of at least X pixels. It is implemented by adding an internal Control node on top of the two children nodes.

Here is an example with a borderless editor test:

Peek.05-09-2022.11-47.mp4

Closes godotengine/godot-proposals#3635

[rburing]

Does this implement godotengine/godot-proposals#3635? :)

[groud]

Does this implement godotengine/godot-proposals#3635? :)

Yeah, I guess it does to some extend. You cannot have the same blue line on the whole width, but the borderless aspect is implemented by this PR, yes.

[akien-mga]

Approved in PR review meeting (pending edit suggested by Yuri).

[akien-mga]

You need to update the class reference to include the new theme properties (and ideally give them a description).

[akien-mga]

Thanks!

[Koyper]

This is a great improvement. I have a scripted version of this with this same approach, but additionally does everything in https://github.com/godotengine/godot-proposals/issues/3635.

Here is what remains to be added to make this fully implement the issue:

1. most importantly, the dragger area requires an additional offset so that if the first child control has a scroll bar, the area doesn't cover part or all of the scroll bar - a new int property like grabber_offset is added to the Rect2 position here:

		if (vertical) {
			dragging_area_control->set_rect(Rect2(Point2(0, middle_sep - (dragger_ctrl_size - sep) / 2), Size2(get_size().width, dragger_ctrl_size)));
		} else {
			dragging_area_control->set_rect(Rect2(Point2(middle_sep - (dragger_ctrl_size - sep) / 2, 0), Size2(dragger_ctrl_size, get_size().height)));
		}

2. emit a new signal dragger_released so that the offset can be saved to a resource and later restored, without having to do it every time dragged emits. This also is very usefull for other post-drag functions.

	if (mb.is_valid()) {
		if (mb->get_button_index() == MouseButton::LEFT) {
			if (mb->is_pressed()) {
				sc->_compute_middle_sep(true);
				dragging = true;
				drag_ofs = sc->split_offset;
				if (sc->vertical) {
					drag_from = get_transform().xform(mb->get_position()).y;
				} else {
					drag_from = get_transform().xform(mb->get_position()).x;
				}
			} else {
				dragging = false;
				queue_redraw();
				sc->emit_signal(SNAME("dragger_released")); // New signal here
			}
		}
	}

3. Make the SplitContainerDragger an exposed class accessible via SplitContainer.get_dragger_control(). Once you have the Control, you can add a draw_line or Panel with StyleBox to set its appearance, and change it's size if required.

It is essential to be able to set a custom size of the dragger Control in the axis of the split line, i.e. top/bottom "margins", as you can do some nifty GUI tricks with that.

[Koyper]

Another nice trick you can do if you have the SplitContainerDragger, is add a button that rides on the split line. For example, an arrow icon that moves items between sides of the split.

[Koyper]

In number 2) above, I am referring to saving/restoring the split_offset...