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: 6257 bytes --]

Martin:

Thanks for commenting on this and sharing some of your extensive knowledge
on window event handling and Emacs.

On Sat, Oct 14, 2017 at 4:35 AM, martin rudalics <rudalics@gmx.at> wrote:

> > ​I think it is a feature that Emacs receives an event for this but a
> defect
> > that it can't distinguish when f2 is atop an external window or not and
> > thus whether the event was actually directed at f2 or not.
>
> ‘mouse-drag-region’ is an Emacs internal function, so it's no defect.
> If it were not internal, Emacs would have to be either able to poll the
> other window's application as to whether it supports dropping an Emacs
> internal string or convert that string to some appropriate coding that
> other applications understand.  Neither of these has been done yet and
> it will be non-trivial to do that for our various platforms.


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

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.

I already have Lisp code doing useful things with such information
(presently, I have to adjust the drag release event information).  So I
know it would be helpful to have this as default Emacs event reporting
behavior.

​​
>
> ​​
> > ​Just FYI, I am using the macOS window manager, not X, though as you
> note,
> ​​
> > it is an issue there too.
> ​​
> > The application-level window managers must have a z-ordering for all
> ​​
> > windows in order to be able to select and raise windows when they are
> ​​
> > behind others.  So you are saying that they don't publish this
> information
> ​​
> > in any useful way that Emacs can obtain, right?
> ​​
>
> ​​
> All I can say is that when you nowadays try to obtain information on
> ​​
> whether a window is really visible under X, chances are that you don't
> ​​
> g
> ​​
> e
> ​​
> t
> ​​
> ​​
> i
> ​​
> t
> ​​
> .


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

> ​
>   Querying the z-order will only tell you something like "window
> ​​
> Y cannot obscure window X because it's lower in the z-order".


​We just want to know when given a screen position whether an Emacs frame
is topmost at that position or not.​
​​​

> ​​
>
> ​​
> > Part of the issue is that the macOS window manager uses click-to-focus,
> so
> ​​
> > the release event of the drag does not switch focus to the application
> ​​
> > whose window the release falls upon.
> ​​
>
> ​​
> As Stefan already mentioned earlier: With a drag operation usually no
> ​​
> focus shifting occurs anyway.


For the interactive things I am doing, I find that selecting the window of
mouse release is always best but I agree it is not necessary in all
instances.

​​
>
> ​
> > However, in drag-n-drop operations,
> ​​
> > the window manager automatically switches focus to any compatible
> ​​
> > application that the mouse moves over (after a delay) so that the right
> ​​
> > application receives the drop (based on Z-order).
> ​​
>
> ​​
> It's completely up to the window manager which polls the application(s)
> ​​
> whether they are ready to receive the object to drop.  Emacs is not
> ​​
> involved in that process.  It would be involved only to tell whether it
> ​​
> would accept such a string when it's the target of a drop.


​I understand that.  I was just noting that there is an example of a drag
release event handler that selects the window of release as a standard part
of its operation.

​​
>
> ​​
>
> ​​
> > Mouse wheel events are also delivered to the topmost Z-order window
> without
> ​​
> > either raising the window or switching focus.
> ​​
>
> ​​
> Mouse wheel events are completely different and highly window system
> ​​
> dependent.  Sometimes they get caught before Emacs sees them at all and
> ​​
> get transformed to scroll bar thumb drag events to the owner of the
> ​​
> scroll bar nearest to the mouse cursor at the time the wheel gets
> ​​
> scrolled.


​Again, I was just providing context of what might be possible based on
other event handling that occurs already in Emacs under macOS.​

​​
>
> ​
> ​​
> > So the window manager always knows where it should deliver
> ​​
>
> ​​
> ... it never "knows".  Some make better guesses and some make worse ...


​On macOS the scroll wheel events seem to go to the right window 100% of
the time from what I have seen.​

​​
>
> ​
> ​​
> > What would the pseudo-code
> ​​
> > look like to check whether or not an Emacs frame was uppermost at the
> point
> ​​
> > of mouse release?
> ​​
>
> ​​
> (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?
​​​

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


​2 seems straightforward.

Bob
​​

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