Introduce a SubViewportContainer config for drag-and-drop target locations

[Sauermann]

With the drag-and-drop rewrite #67531, SubViewportContainer nodes were no longer available as drop-locations.
A detailed explanation of this situation is available in #99155 (comment).

This PR introduces a configuration option, that allows SubViewportContainer to be considered as drop-location, but disables the Control nodes inside its SubViewport children as drop-locations. The reasoning for this either-or-approach is also explained in #99155 (comment).

With this setup, it is possible to use the SubViewportContainer as drop-location, while at the same time use physics-picking inside the SubViewports of the SubViewportContainer.

• resolve [Regression] SubViewportContainer doesn't call _CanDropData event #99155
• alternative to/supersedes Enable SubViewportContainer as a potential candidate for dropping in Drag&Drop #99209

[tetrapod00]

Suggested change

	If [code]false[/code], the [SubViewportContainer] is not available as drop location in drag-and-drop operations, but all of the [Control] nodes inside its [Viewport] children.
	If [code]false[/code], the [SubViewportContainer] is not available as a drop location in drag-and-drop operations, but all of the [Control] nodes inside its [Viewport] children.

Missing word?

Also, why is the false case listed before the true case? I think most of the time we list the true case first, but I'm not sure if it's a hard rule

[Sauermann]

false is the default value of the parameter, so I put its description first. If the other order would make more sense, I am happy to change it.

[tetrapod00]

That makes sense, and there is some precedent for putting false first. See what everyone else thinks

[conde2]

@Sauermann if I understood correctly this #99155 will make only SubViewportContainer receive the drag and drop events when the option is checked.

But I have inside this SubViewportContainer all my game components like inventory slots, equipment slots that depend on the drag and drop system.

So I'm afraid we will still face some regression that can't be worked around. Wouldn't we?

Before in 4.3 even with the SubViewportContainer occupying the entire screen and physics picking enabled, it was still possible to perform drag and drop in the children of the SubViewportContainer, is this what going to happen with #99155?

[Sauermann]

@conde2

I would like to understand the problem you are facing, but I am not entirely sure, if I understand you correctly. Let me try to explain your situation in my words and please let me know, if you agree:

You want to utilize for drag-and-drop at the same time:

• The SubViewportContainer as drop location
• The Control nodes inside the SubViewport as drop location

Can you please elaborate, what you would expect to happen, when the user uses drag-and-drop and drops to the location of a Control node inside the SubViewport, the problem being, that both the SubViewportContainer and the Control node inside the SubViewport are located at this position. Should either the SubViewportContainer receive the drop event, or alternatively should the Control node receive the drop event?

For reference: Before #67531, drag-and-drop with Control nodes in SubViewports was mostly unusable. For example, it was impossible to use drag&drop from Control nodes of the main viewport to Control nodes in the SubViewport. It was also impossible in secondary Windows to drop to Control nodes in SubViewports from anywhere. Another impossible thing was to drag from Control nodes in the SubViewport to Control nodes in the main viewport. So I am not entirely sure, which regression it is, that you mention.

[conde2]

You want to utilize for drag-and-drop at the same time:

The SubViewportContainer as drop location
The Control nodes inside the SubViewport as drop location

That's exactly my setup in 4.3, and it worked out of the box. Top layer SubViewportContainer with drop events then a Subviewport with physics picking and inside it some controls with drag and drop events.

I'm not at home right now to show some screenshots of my game setup, as soon as I'm able to do it I will update this comment.

But basically why not setup some order to call the event? Maybe bottom up to call the drag and drop events? As soon as it find a viable drop control inside mouse position it call the event for that specific container, also consider the canvas layer index?

This would create a previsible and consistent manner of how events are called.

[Sauermann]

@conde2 Thanks for your answer. To clarify more. Is the following description correct?

• When you start drag-and-drop on a Control node in the main viewport, you want to drop on the SubViewportContainer, but not on the Control nodes inside the SubViewport.
• When you start drag-and-drop on a Control node in the SubViewport, you want to drop on other Control nodes inside the viewport, but not on the SubViewportContainer.

[conde2]

Thanks for the answering and help with this issue @Sauermann.

I just got home, here is how my game nodes setup:
Game and GameGui are children of the MainViewport.

When you start drag-and-drop on a Control node in the main viewport, you want to drop on the SubViewportContainer, but not on the Control nodes inside the SubViewport.

Thats correct, I by mistake said that the drag and drop was coming from a child of the SubViewport but thats not true, sorry for that, I will clarify better what is happening.

Here I'm dragging from a Control that is child of the MainViewport to the SubViewportContainer.
The SubViewportContainer is the DropLocation holding both events: _CanDropData and _DropData

The.Last.Magic.DEBUG.2024-11-17.19-37-25.mp4

Here I'm dragging from a Control that is child of the MainViewport to another Child of the MainViewport
The Inventory Slot and Actionbar Slot is a Control that is the DropLocation holding both events: _CanDropData and _DropData

The.Last.Magic.DEBUG.2024-11-17.19-38-18.mp4

Here I'm moving my mouse on top of the Item with a CollisionArea to detect the mouse and item area. That requires physics picking in the subviewport.

The.Last.Magic.DEBUG.2024-11-17.19-42-25.mp4

[Sauermann]

@conde2 thank you for the clarification. So you don't have any Control nodes inside the SubViewport, that are drag-and-drop drop-locations.
All three cases, that you describe, are covered by the changes of this PR. In order for this to work, you would need to set consume_drag_and_drop = true.

[akien-mga]

Makes sense to me overall, based on the linked issue it sounds like this needs to be configurable behavior.

[conde2]

@akien-mga is it possible to get his in time for 4.4 dev5 ?

It makes 4.4dev unusable for me without this fix. And adding this I can test and check if its all good.

[akien-mga]

4.4 dev 5 was already built and will be released later today, so this will be for dev 6.

[Repiteo]

Thanks!