-
-
Notifications
You must be signed in to change notification settings - Fork 21.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable Drag and Drop between SubViewports and Windows #67531
Conversation
9c955b3
to
1b2ea91
Compare
@rokiyo Thanks, I did not see these. |
efe0752
to
1f07643
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to be working fine.
Note: At least on macOS, mouse cursor is changed to <->
when crossing resizable window border, and not restored to DnD cursor afterwards (until drop target is hovered).
6b25c96
to
a52d416
Compare
That sounds like Godot believes that the mouse cursor is still |
a52d416
to
c20e855
Compare
@Sauermann how is your progress with this PR? |
@Chaosus Also #58334 will cause a few small adjustments to this PR, but I consider them minor. Ideally I would prefer, that #58334 should be merged before this PR, but that is not strictly necessary. |
I wrote #71509 as a far simpler way to solve this. I believe It fixes drags/drops accross viewports more elegantly. What is missing is proper drag previews across windows, but the correct solution to this in my mind is to use borderless, transparent, passthrough windows similar to what we use with tooltips. |
The complexity in this PR comes from the fact that is solves three problems:
In order to be able to compare it with #71509 (which aims to solve 1), I believe, that I should extract the part of this PR, that solves 1, so that they can be compared better. It looks like I am struggling again with packing too much content into a single PR. From a quick comparison, this approach makes Drag and Drop an application-wide operation, while #71509 uses a heuristic to determine a Viewport to use as a base for the Drag and Drop operation. |
Could use testing on macOS (and review if you can) @bruvzg |
82cb5f9
to
70b3d18
Compare
This is if not the most important feature to distinguish between flutter and godot. |
0f9ae17
to
277584e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Let's merge if you think now would be a good time.
We decided to keep this for the 4.4 cycle, as it's pretty late now in the 4.3 cycle and this PR changes behavior in a way that may clash with user expectations. So we don't want to rush it / have to reconsider the design during the 4.3 beta/RC stage. |
277584e
to
9d418e8
Compare
Make Drag and Drop an application-wide operation. This allows do drop on Controls in other Viewports/Windows. In order to achieve this, `Viewport::_update_mouse_over` is adjusted to remember the Control, that the mouse is over (possibly within nested viewports). This Control is used as a basis for the Drop-operation, which replaces the previous algorithm, which was only aware of the topmost Viewport. Also now all nodes in the SceneTree are notified about the Drag and Drop operation, with the exception of SubViewports that are not children of SubViewportContainers.
6bc76a9
to
60aaa01
Compare
So now would be a good time to merge this for 4.4 I think? |
Thanks! |
Make Drag and Drop an application-wide operation.
This allows to drop on Controls in other Viewports/Windows.
Also now all nodes in the SceneTree are notified about the Drag and Drop operation, with the exception of SubViewports that are not child-nodes of SubViewportContainers. This distinction seemed prudent, because these SubViewports need to be displayed manually and this requires manual setup also for Drag and Drop.
Unit-tests for Drag and Drop in different Windows & SubViewports are also added.
In order to achieve this, the following changes were made:
Viewport::_update_mouse_over
from Refactormouse_entered
andmouse_exited
signals #67791 is used to identify the drop-target (even within nested viewports)is_directly_attached_to_screen
is replaced byget_section_rootviewport
. which is of the same complexity, but additionally returns the topmost Viewport within the section_propagate_viewport_notification
had to be adjusted to account for sectionsDisplayServerX11::delete_sub_window
needed to be adjusted similar to Fix crash on Windows when closingWindow
#80142, since the event-callback is also needed on linuxbsd during Window-deletionRelations:
!get_viewport()->gui_is_dragging()
when usingset_drag_preview
from a sub-window #59622mouse_entered
andmouse_exited
signals #67791Window
#80142MRP: BugDragNDrop.zip (updated 2023-01-20)
The Drag-Preview in the following Video is outdated, because that will be done in a different PR.
BugDragNDrop.mp4
Updated 2023-01-28: Fix merge conflict
Updated 2023-03-20: Fix merge conflict
Updated 2023-05-30: Linked another bug-report, that this PR fixes. Resolve problematic testcases. Fix merge conflict.
Updated 2023-06-07: Fix merge conflict
Updated 2023-06-08: Fix issue with docks
Updated 2023-06-19: Fix issue with simultaneous drag starts
Updated 2023-07-06: Fix issue with Gui in 3D Demo, Add Unit-tests
Updated 2023-07-19: Fix merge conflict
Updated 2023-08-02: Fix merge conflict with #67791 and #79805
Updated 2023-08-12: Fix merge conflict
Updated 2023-09-18: Fix merge conflict with #81551
Updated 2024-01-03: Fix merge conflict with #86511 and verified that #86493 doesn't get reintroduced.
Updated 2024-05-03: Rebased after #91425 and verified that #91387 doesn't get reintroduced.
Updated 2024-09-15: Rebased after 4.3-release for good measure and verified the functionality in the MRP.