Editor: Add highlight around docks when dragging

[lodetrick]

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.

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

This PR also creates the EditorDockDragHint node to contain the logic.

[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)).

[lodetrick]

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!

[lodetrick]

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.

[lodetrick]

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:

[lodetrick]

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

[kitbdev]

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.

[lodetrick]

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?

[kitbdev]

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.

[lodetrick]

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]

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.

[lodetrick]

I've cleaned up the code some more, and made the center a transparent color corresponding to the edge color, its subtle but I like it. I also extracted the tab drop drawing logic into its own function so both the TabBar and DragHint classes can use it.

[kitbdev]

Works as expected.
Can be improved in the future with dragging to closed slots, and _get_dock_tab_dragged logic can be simplified with some kind of Dock manager control.