bug#65008: 29.1; Feature: dired-mouse-drag-files for Wayland

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Huan Thieu Nguyen <hnguyen@hyperstone.com> writes:

> Hi, why does this feature exclude Wayland? It's possible to do with
> GTK3. I might be able to help, but I've only done it with GTK4 which
> changed it a bit <https://docs.gtk.org/gtk4/migrating-3to4.html#switch-to-the-new-drag-and-drop-api>

Patches welcome.  I set out to implement this last year, but found
several severe problems with GDK's crude Wayland drag-and-drop
implementation preventing it from matching Emacs's expectations.

The GDK Wayland backend's drag and drop interface returns a placeholder
window from `gdk_drag_find_window_for_screen', presuming that the
program implementing DND will immediately call `gdk_drag_motion' with
updated drag-and-drop information.  Emacs needs to know exactly which
window is under the pointer (and also the position of the pointer
device) in order to display and position the optional DND tooltip and
possibly cancel DND if the pointer moves back into a frame.

These problems eventually boil down to the inability of Wayland clients
to terminate drags they initiate, and Wayland's refusal to provide the
client with the surface under the pointer during a drag.

As a consequence, Emacs can't return to Lisp when the mouse pointer
returns to the confines of a frame, nor can it quit out of drag and drop
operations.

If you do want to pick up where I left off, keep in mind that Emacs
can't make use of the higher level GTK drag-and-drop interface: it must
employ the GDK drag-and-drop primitives, since only those enable
selection data to be transferred.  You will want to implement the
function `x-begin-drag'; refer to its documentation and the
implementations in xfns.c, ns-win.el and haiku-win.el for more details.