Editor: Add highlight around docks when dragging #106762

lodetrick · 2025-05-23T22:46:04Z

Closes godotengine/godot-proposals#12489

Adds a highlight around docks when dragging that tells you whether you can drop a dock. Also increases the area to drop docks to the entire TabContainer.

There is multiple colors that the highlight could be depending on whether it is a valid dragging operation (say if you were trying to drag a vertical dock into the bottom panel), but currently no container is marked as horizontal so this won't go into effect.

Screen.Recording.2025-05-23.at.2.51.05.PM.mov

This PR also creates the EditorDockTabContainer class to contain the logic.
The primary issue that I ran into was that all the buttons and internal components in the docks stopped mouse input, so dragging and checking if the mouse was contained by the rect wouldn't work as expected (and in the case of the Scene Dock it would only work in the small margins in between buttons), which is why I pivoted to using input.

Calinou

Tested locally, it works as expected. This is a nice usability improvement 🙂

My only concern is that the width of the drag border hint is a bit too wide by default. It also varies depending on the editor spacing preset chosen, and it'll be invisible with the Compact spacing preset:

Default

Spacious

Compact

I suggest using a fixed value that's identical to the standard focus outline (Math::round(2 * EDSCALE)).

editor/editor_dock_manager.cpp

lodetrick · 2025-05-24T19:01:01Z

Thanks for the tips! I changed the width to a constant, and removed the dock_margin variable because it was only used to keep track of the border width. I draw the highlight outside of the rect for it to not be obscured by the TabBar (I can't change the z-index of the TabBar because the tabbar background would draw over them), so it is slightly smaller on the edge of the window in the compact mode.

Calinou

Looks great now!

editor/editor_dock_manager.cpp

editor/editor_dock_manager.h

lodetrick · 2025-05-27T23:05:25Z

Thanks for the tip on call_deferred(), that was really bugging me. I incorporated the rest of your suggestions into the code, and got rid of the unnecessary EditorDockTabContainer mentions.

kitbdev · 2025-05-28T01:25:53Z

The drop_data and other methods are intended to only be called from the Viewport, this is fighting with the drag and drop system, as can be seen with the cursor workaround.
I was imagining dynamically creating new Controls that cover the TabContainer's contents on drag start, this way we can have more drop targets than just in the TabContainers (eg. to move to dock slots with no tabs), the contents wouldn't receive their own can_drop, and it would work with the drag and drop system better.
Though I'm not sure if there are any problems with that approach, and I wanted to get a better idea of how floating docks could support it before trying it.

Edit: It would probably also fix FileSystem scrolls when moving a dock tab below it #93755. Or maybe not, since it just happens on process.

lodetrick · 2025-05-28T01:32:15Z

Thats a good idea, I'll play around with it. I think that floating docks right now are more about docks themselves rather than the TabContainers though, so I don't know if they should be supported.

lodetrick · 2025-05-28T11:14:42Z

Ok, I tried to create floating controls that would allow users to place docks in hidden TabContainers. The code for deciding on the rects was rather large. I am aware that when the bottom right dock slot of the left or right is unfilled it does look a bit weird. I'm curious what others think about this:

editor/editor_dock_manager.h

editor/editor_dock_manager.cpp

lodetrick · 2025-05-28T17:48:15Z

There were a few visual changes, primarily that the dragging hints will only be shown when hoverred on, and the visual side of the rect is now fit to the TabContainer, but the interaction is not. The clip shows an example of this:

Screen.Recording.2025-05-28.at.10.45.16.AM.mov

editor/editor_dock_manager.cpp

kitbdev · 2025-05-28T18:11:02Z

editor/editor_dock_manager.cpp

+		int dock_hidden_size = 28 * EDSCALE;
+		int dock_hidden_offset = dock_hidden_size + 4 * EDSCALE;
+		Rect2 temp_dock_drag_rects[DOCK_SLOT_MAX];
+		temp_dock_drag_rects[DOCK_SLOT_LEFT_UL] = dock_slot[DOCK_SLOT_LEFT_UL]->get_global_rect();


This can just cover the contents, so the TabContainer drag and drop logic works the same as before, and dropping it on the contents just adds it to the end.
dock_slot[i]->get_current_tab_control()->get_global_rect();.

And this logic to set the rects should be from EditorDockManager's drag begin notification, so it only happens once instead of for each one.

Unfortunately since EditorDockManager is an Object and not in the tree, it does not receive the drag notification. However, I already have safeguards against computing the information multiple times, it stores the output and has an early return if the output is already known for the current drag.

Although if I limit the drop rect to the child control, then the highlight won't appear when the mouse is over the tabbar unless I returned to using input(). What do you think about this?

If it doesn't get the notification, then it is fine. In the future we may want to move some dock management into a Control.

I think it's fine to not highlight when the mouse is over the TabBar, since it has its own drop highlight and it allows moving the tab to a different index.

Actually thinking about it, I do think that we should override the TabBar drag and dropping. If we want to limit where the dock can be dropped (ie for different horizontal / vertical layouts), we need to change the behavior somewhat, and I think that this is the place. I might try and see if I can somehow update the TabBar's drop hint.

lodetrick · 2025-05-29T02:33:22Z

It should be back to the original design from a user standpoint, but with a control as the backend, cleaning up the implementation a lot. There's a few changes that should be made once the EditorDock PR is merged, but until then it is good.

kitbdev · 2025-05-29T20:46:35Z

editor/editor_dock_manager.cpp

+		int drop_tab = dock_manager->dock_slot[occupied_slot]->get_tab_bar()->get_closest_tab_idx_to_point(p_point);
+		dock_manager->_move_dock(dragged_dock, dock_manager->dock_slot[occupied_slot], drop_tab);


Dropping the tab on a dock should move it to the end by default, currently it never puts it at the end.
I think only when the tab is over the TabBar part should you be able to change the index.

kitbdev · 2025-05-29T20:54:35Z

editor/editor_dock_manager.cpp

+
+		for (int i = 0; i < DOCK_SLOT_MAX; i++) {
+			if (dock_slot[i]->is_visible_in_tree()) {
+				dock_drag_rects[i]->set_rect(dock_slot[i]->get_global_rect());


I'm still not sure why the TabBar needs to be covered. For moving to closed slots in the future, it can either be on top of the TabBars or work around it, since dropping directly into the TabBar should probably always drop into the TabBar.
If it is needed for some reason, then the TabBar's tab drag index highlight should be recreated so you know what index the dock will be at when dropped.

kitbdev · 2025-05-29T21:10:19Z

editor/editor_node.cpp

@@ -7717,6 +7717,7 @@ EditorNode::EditorNode() {
 	editor_dock_manager->add_hsplit(main_hsplit);
 	editor_dock_manager->add_hsplit(right_hsplit);

+	// Register dock TabContainers.


Suggested change

// Register dock TabContainers.

This isn't really needed.

kitbdev · 2025-05-29T21:20:01Z

editor/editor_dock_manager.cpp

+				dock_found = true;
+			}
+		}
+		if (!dock_found) {


Suggested change

dock_found = true;

}

}

if (!dock_found) {

break;

}

}

if (!dock_tab_dragged) {

kitbdev · 2025-05-29T21:27:27Z

editor/editor_dock_manager.cpp

+
+	set_as_top_level(true);
+	dock_drop_highlight.instantiate();
+	dock_drop_highlight->set_draw_center(false);


Maybe this should draw a partially transparent center so it is more clear that it isn't for the dock's content?

lodetrick requested review from a team as code owners May 23, 2025 22:46

lodetrick changed the title ~~Improve editor dock dragging usability~~ Add highlight around editor docks when dragging May 23, 2025

lodetrick force-pushed the dragging-docks branch from ca5fba9 to 56502b3 Compare May 23, 2025 23:17

lodetrick changed the title ~~Add highlight around editor docks when dragging~~ Editor: Add highlight around docks when dragging May 24, 2025

lodetrick force-pushed the dragging-docks branch from 56502b3 to 5a576a1 Compare May 24, 2025 10:09

AThousandShips added enhancement topic:editor labels May 24, 2025

AThousandShips added this to the 4.x milestone May 24, 2025

Calinou reviewed May 24, 2025

View reviewed changes

editor/editor_dock_manager.cpp Outdated Show resolved Hide resolved

Calinou reviewed May 24, 2025

View reviewed changes

editor/editor_dock_manager.cpp Outdated Show resolved Hide resolved

lodetrick force-pushed the dragging-docks branch from 5a576a1 to 1d3a718 Compare May 24, 2025 18:56

lodetrick force-pushed the dragging-docks branch from 1d3a718 to 75ca1f0 Compare May 26, 2025 05:31

Calinou approved these changes May 27, 2025

View reviewed changes