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

[Robert Weiner]

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

​