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

[Robert Weiner <rsw@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 4490 bytes --]

On Sun, Oct 15, 2017 at 5:40 AM, martin rudalics <rudalics@gmx.at> wrote:

>
> 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.


​Yes.  My point is that there should be some extension to Emacs'
reporting of window system events that allows a user of such
information to know whether any other application occluded the
Emacs frame at the time and point of release.  Then in cases
where this information can be gleaned from the external window
manager, it can be used in programs.  The user program is still
free to allow a drop to go through in such cases but only if
desired.

​​
>
> ​​
> > 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
> ​​
> f
> ​​
> o
> ​​
> l
> ​​
> l
> ​​
> o
> ​​
> w
> ​​
> ​​
> a
> ​​
> ​​
> s
> ​​
> t
> ​​
> a
> ​​
> n
> ​​
> d
> ​​
> a
> ​​
> rd interface for the OS used.


​It is not only drag-and-drop that we are interested in.  We
often want to simply call different functions based on whether
the drag release was inside or outside of Emacs.  For example,
Hyperbole now uses a drag release outside of Emacs to clone the
window depressed upon into a new frame.​

​​
>   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?


​Yes, you would need to follow a common drag-and-drop protocol.
I don't understand why that is an issue if that is what you want
to do.

​​
>
> ​
> > ​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,


For programmatic purposes when Emacs receives a mouse button
drag release event, we only care about whether the topmost
window-system window at the point of release is an Emacs frame
or not.  If at that point, it is occluded by another window,
we don't care how transparent that window is and whether the
Emacs frame can be "seen" but only whether it is logically
the window clicked upon.  Again, even if it is not, we can
process the event as if it were *if we so choose* but having
the choice is the key issue here.

​​
>
> ​​
>
> ​​
> >> (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.


​Could you give a concrete example of where this might be a problem
so I could test code against it?
​

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

​I have figured that part out from the macOS APIs.
​
Bob
​

[-- Attachment #2: Type: text/html, Size: 14055 bytes --]