bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[martin rudalics <rudalics@gmx.at>]

 > ​Ok, that indicates that drag-and-drop from Emacs to external applications
 > is unlikely but it still leaves the issue of recognizing whether a drag
 > release event maps to an Emacs frame or not (when the frame is covered by
 > an external app's window).  I already have code that recognizes this in
 > Lisp; we should make it a primitive so the drag release code in Emacs could
 > report more useful and accurate information in drag release events.

Even if the Emacs frame is covered by another application's frame,
nothing prevents us from having that covered Emacs frame accept the
drop.  We could even give frames a "no-accept-drops" parameter and this
way have a drop on such frames pass the drop through to yet another
frame below that does accept drops.

 > I guess you are saying that Emacs drag events must start and end within
 > Emacs frames.  I think about it a bit differently.  Since the mouse can
 > move in and out of Emacs frames and release events can occur (in logical
 > Z-ordered OS window space) outside of Emacs, yet still register with Emacs
 > (when the release occurs within the geometry of a frame but the frame is
 > covered by another app's window), I think Emacs event handling should
 > return different information when the release frame is not the topmost
 > OS-level window at the point of release.  Then handler code could dispatch
 > as necessary.

But to be useful, that "handler code" must be written and such code must
follow a standard interface for the OS used.  Consider the trivial task
that one Emacs instance wants to drop some text to a second Emacs
instance.  How would we trigger the drop event on that second instance?

 > ​Each window has a 'visible' attribute.  Are you saying this is not
 > accurate these days?​

Yes.  The GTK manual says that

   Modern composited windowing systems with pervasive transparency make
   it impossible to track the visibility of a window reliably,

 >> (1) ‘frame-list-z-order’ would have to be able to return all windows on
 >> ​​
 >> your system
 >
 >
 > ​Is it likely we could build a multi-platform primitive ​that would supply
 > that information given what you have said?

At least for top-level windows.  This will work as long a child windows
are fully contained by their parents which IIUC is not necessarily true
for macOS systems.

 >> and (2) a function would be needed to get the attributes of
 >> ​​
 >> those windows.
 >
 >
 > ​2 seems straightforward.

How accurate these attributes will be depends on the windowing system
used.  Look at how hard frame_geometry occasionally works to just get
the real screen estate of an Emacs frame.

martin