DnD under Windows needed 3 fixes to work with Gtk.DropTarget.
The droptarget_w32format_contentformat_map list never gets filled so the gdk_win32_drop_read_async throws "No compatible transfer format found". This is an easy fix and done the same way in the win32 clipboard code.
After a drop no gdk_drop_emit_leave_event gets emitted. This causes a second drop to trigger a bunch of assertion 'self->drop == drop' failed because the first drop is still active. This is also an easy fix and done the same way by the macos backend.
Handling gdk_drop_status/gdk_drop_get_actions interaction. In gtk_drop_target_do_drop the code
gdk_drop_finish (self->drop, gdk_drop_get_actions (self->drop));calls the finish operation with the actions of the drop which triggers
g_return_if_fail (gdk_drag_action_is_unique (action));in gdk_drop_finish. The code assumes that GdkDrop::actions gets narrowed down by calling gdk_drop_status. This is hard to assure because at the same time gdk_drop_get_actions is used by gtk_drop_target_accept to figure out if a drag is accepted. GdkDrop::actions serves a double purpose here as the supported source actions and the currently agreed on action. Both the x11 and the wayland backend get this wrong somewhat too. Under wayland/x11 when a drag coming from a source that supports both MOVE and COPY is first hovering a drop target that only supports COPY it is afterwards no longer accepted by other drop targets only accepting MOVE. Under x11 this is permanent for this drag but with wayland the drag recovers when hovering other widgets. The win32 backend now sets the supported source actions before any enter/move/drop and narrows them down in gdk_win32_drop_status.
The patch only touches the win32 backend and fixes all three issues, for me restoring DnD under windows.
Closes #4498 (closed)