Implement automatic snapping in split containers #106323

badsectoracula · 2025-05-12T21:47:03Z

Closes godotengine/godot-proposals#12417.

Implement automatic snapping in split containers so that when the user drags the splitter beyond a threshold after the minimum size of a child, it "snaps" to the appropriate edge (left/right for horizontal arrangement, top/bottom for vertical arrangement), causing the child look as if it disappeared. The splitter can still be dragged back to reveal the child.

Visually this looks similar to collapsing but functionally it differs as it only affects the visual state of the nodes.

The proposal contains a video of this in action.

Production edit: This partially addresses
Make the individual editor side docks minimizable using keyboard shortcuts godot-proposals#1441 (requires mouse to hide individual docks).

Calinou

Tested locally, it mostly works as expected.

Some feedback:

There's an issue where clicking the bottom panel for the first time will hide it immediately (since it tries to resize to the minimum possible size, which now hides it entirely). This is also why the bottom panel isn't visible anymore while the editor is still starting (and restoring scenes from the previous session).
Hiding the bottom panel completely when you drag it all the way down might be confusing. I can see a lot of users wondering where the bottom panel went and having to resort to restarting the editor to get it back.
- Maybe dragging the bottom panel all the way down should just collapse it (like when you click on the name of the current bottom panel), and hiding it entirely should be left to a dedicated button in the bottom panel.
- This issue also applies to the side docks, but it's probably less extreme. In any case, we might need to show some kind of notice the first time you collapse any of the docks in an editor session. One of my UX pet peeves in software is when I manage to hide something and have no idea how to undo it 🙂¹

Additionally, if you hide both docks and toggle distraction-free mode, it will appear to do nothing (except cause a very slight UI shift on the left side, which may indicate a leftover spacer control or similar):

distraction_free_hide_docks.mp4

This is a good opportunity to make distraction-free mode hide the bottom panel again, now that you get more control over what to hide. This has been a recurring request over the years: godotengine/godot-proposals#9141

If you've pressed Tab while using GIMP, you know. ↩

doc/classes/SplitContainer.xml

syntaxerror247 · 2025-05-13T19:01:14Z

Sorry about the misclick — I'm on mobile.

syntaxerror247 · 2025-05-13T19:04:56Z

While testing this PR, I noticed that in the ProjectSettings or EditorSettings window, the left panel was already snaps to the edge. This behavior doesn't seem intentional — is that expected?

arkology · 2025-05-13T19:26:22Z

Also it's possible to hide center panel, this is definitely not intended 😄

…r drags the splitter beyond a threshold after the minimum size of a child, it "snaps" to the appropriate edge (left/right for horizontal arrangement, top/bottom for vertical arrangement), causing the child look as if it disappeared. The splitter can still be dragged back to reveal the child. Visually this looks similar to collapsing but functionally it differs as it only affects the visual state of the nodes.

badsectoracula · 2025-05-14T00:25:54Z

Made some changes based on the comments:

Instead of trying to infer snapping from the splitter position (split offset) the code now uses an explicit snap state. The snap state can be set programmatically (this also allows saving the snap state as part of the editor layout).
Autosnapping updates the snap state based on the flags like before (i changed the constant names to reflect that they're used for both autosnap setting and the snap state).
A signal is emitted whenever the snap state changes.
The dragging state of the dragger is reset when a property (e.g. collapsed) is set to a value that causes dragging impossible while dragging (this was an existing bug that i found while trying to implement the other stuff).
For the bottom button panel when dragging ends that would end up in a snapped position, the snapping is reset and instead:
- When trying to snap at the bottom of the screen, the panel collapses its (as if someone clicked on the active button)
- When trying to snap at the top of the screen, the editor enters in distraction free mode
The snapping state for the dock splits is now stored in the current editor layout. The default layout is updated with snapping disabled (so someone selecting to restore the default layout with snapped dock splitters will have these splitters unsnapped).

For the bottom button panel i tried to have it enter in the collapsed mode automatically while dragging but because the buttons themselves are inside the splitter and collapsing it causes all sorts of other side effects the code was becoming way too gnarly for something that seems like a very special case, so instead i made the bottom panel collapse after the drag finishes (the effect is almost the same, except you can drag the splitter all the way to the bottom but once you release the mouse button the buttons "pop" back out). To make this happen while dragging it'd require moving the buttons outside the splitter, but this felt like a much more intrusive change to me.

Also note that while the default setting is to allow autosnapping for both children, this can be changed in cases where autosnapping needs to be done only for one child or disabled. However i think having the default be to autosnap for both is more useful as it'd allow pretty much every splitter to snap and save screen real estate across the editor without any changes (it does cause the unit tests for dragging to fail though so i'll need to see what to do with that).

KoBeWi · 2025-05-26T15:18:58Z

Using FIRST/SECOND as snap target will conflict with #90411
Not sure how to handle that though, ideally the other PR should be merged first, but it may take a while 🙃

AThousandShips · 2025-05-26T15:59:49Z

Btw the title of this commit is far too long, the commit description and title should be brief and clear

KoBeWi · 2025-05-26T21:15:21Z

editor/gui/editor_bottom_panel.cpp

+		case NOTIFICATION_EXIT_TREE: {
+			SplitContainer *center_split = Object::cast_to<SplitContainer>(get_parent());
+			ERR_FAIL_NULL(center_split);
+			center_split->disconnect(SNAME("drag_ended"), callable_mp(this, &EditorBottomPanel::_center_split_drag_ended));


Why are you disconnecting the signal?

Restoring the state as it was before the node entered the tree since i connect the signal on NOTIFICATION_ENTER_TREE i thought it'd be a good idea to disconnect it in NOTIFICATION_EXIT_TREE.

But bottom panel enters and exits tree when the editor starts and closes, it happens only once. It's irrelevant if the signal stays connected.

You are correct, if it happens only once then it is not necessary to remove it, i'll update the code later to remove this part.

KoBeWi · 2025-05-26T21:16:00Z

editor/gui/editor_bottom_panel.cpp

@@ -100,6 +112,31 @@ void EditorBottomPanel::_update_disabled_buttons() {
 	right_button->set_disabled(h_scroll->get_value() + h_scroll->get_page() == h_scroll->get_max());
 }

+void EditorBottomPanel::_center_split_drag_started() {
+	SplitContainer *center_split = Object::cast_to<SplitContainer>(get_parent());
+	ERR_FAIL_NULL(center_split);


Pretty sure this check is only needed once, when connecting the signal. The bottom dock does not move.

KoBeWi · 2025-05-26T21:19:51Z

scene/gui/split_container.cpp

+void SplitContainer::_fit_child_in_rect_with_visibility_update(Control *p_child, const Rect2 &p_rect) {
+	// For very small rects (like when a size is set to 0 via autosnapping) hide the child instead


This is misleading, because visibility is not being changed.

Depends on how you think about it, from a technical perspective it changes the scale so it doesn't actually change its visibility flag, but from the user's perspective it makes the child disappear, so it does change its visibility. The goal of the function is to update the visibility from the end user's perspective even if from the technical side it changes its scale - hence the reason i added the comment to clarify what is going on and why.

You could say like "disappear from view" because "hide", "show", "visibility", etc. have very specific meanings for CanvasItem & co.

KoBeWi · 2025-05-26T21:20:10Z

scene/gui/split_container.cpp

@@ -245,7 +263,26 @@ void SplitContainer::_compute_split_offset(bool p_clamp) {
 	// Clamp the split offset to acceptable values.
 	int first_min_size = first->get_combined_minimum_size()[axis_index];
 	int second_min_size = second->get_combined_minimum_size()[axis_index];
-	computed_split_offset = CLAMP(wished_size, first_min_size, size - sep - second_min_size);
+
+	// Check autosnapping


Suggested change

// Check autosnapping

// Check autosnapping.

Same in all comments.

badsectoracula requested review from a team as code owners May 12, 2025 21:47

badsectoracula added enhancement topic:gui labels May 12, 2025

badsectoracula force-pushed the pr-splitcontainer-autosnap branch from df9270c to 42271a0 Compare May 12, 2025 21:56

Calinou added the topic:editor label May 12, 2025

Calinou added this to the 4.x milestone May 12, 2025

Calinou reviewed May 12, 2025

View reviewed changes

doc/classes/SplitContainer.xml Outdated Show resolved Hide resolved

Calinou reviewed May 12, 2025

View reviewed changes

doc/classes/SplitContainer.xml Outdated Show resolved Hide resolved

syntaxerror247 closed this May 13, 2025

syntaxerror247 reopened this May 13, 2025

badsectoracula force-pushed the pr-splitcontainer-autosnap branch from 42271a0 to 289e7af Compare May 13, 2025 23:39

badsectoracula requested review from a team as code owners May 13, 2025 23:39

badsectoracula force-pushed the pr-splitcontainer-autosnap branch from 289e7af to 61af908 Compare May 13, 2025 23:40

badsectoracula force-pushed the pr-splitcontainer-autosnap branch from 61af908 to 780a344 Compare May 14, 2025 00:14

AThousandShips changed the title ~~Implement automatic snapping in split containers so that when the use…~~ Implement automatic snapping in split containers May 26, 2025

KoBeWi reviewed May 26, 2025

View reviewed changes

		void SplitContainer::_fit_child_in_rect_with_visibility_update(Control *p_child, const Rect2 &p_rect) {
		// For very small rects (like when a size is set to 0 via autosnapping) hide the child instead

Uh oh!

Implement automatic snapping in split containers #106323

Are you sure you want to change the base?

Implement automatic snapping in split containers #106323

Conversation

badsectoracula commented May 12, 2025 • edited by Calinou Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Calinou left a comment

Choose a reason for hiding this comment

Footnotes

Uh oh!

Uh oh!

Uh oh!

syntaxerror247 commented May 13, 2025

Uh oh!

syntaxerror247 commented May 13, 2025

Uh oh!

arkology commented May 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

badsectoracula commented May 14, 2025

Uh oh!

KoBeWi commented May 26, 2025

Uh oh!

AThousandShips commented May 26, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

badsectoracula Jun 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

badsectoracula commented May 12, 2025 •

edited by Calinou

Loading

arkology commented May 13, 2025 •

edited

Loading

badsectoracula Jun 3, 2025 •

edited

Loading