GNU bug report logs -
#28620
Mouse drag event records wrong window for release when crossing frames
Previous Next
Reported by: rswgnu <at> gmail.com
Date: Wed, 27 Sep 2017 15:45:01 UTC
Severity: normal
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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 <at> 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
[Message part 2 (text/html, inline)]
This bug report was last modified 4 years and 333 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.