From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.bugs Subject: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window Date: Sat, 14 Oct 2017 13:16:55 -0400 Message-ID: References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <83vajwytja.fsf@gnu.org> <83poa4yqyq.fsf@gnu.org> <83376qouoj.fsf@gnu.org> <59DF2260.5030204@gmx.at> <59E1CC55.2090400@gmx.at> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114d6da08149f4055b84f226" X-Trace: blaine.gmane.org 1508001549 22756 195.159.176.226 (14 Oct 2017 17:19:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 14 Oct 2017 17:19:09 +0000 (UTC) Cc: Alan Third , 28620@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 14 19:19:03 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3Q5P-00045O-JD for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Oct 2017 19:18:56 +0200 Original-Received: from localhost ([::1]:54674 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3Q5X-0001kt-1S for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Oct 2017 13:19:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3Q4c-0001Nu-3q for bug-gnu-emacs@gnu.org; Sat, 14 Oct 2017 13:18:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e3Q4Y-0001jK-Sl for bug-gnu-emacs@gnu.org; Sat, 14 Oct 2017 13:18:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60016) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e3Q4Y-0001j9-Oo for bug-gnu-emacs@gnu.org; Sat, 14 Oct 2017 13:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e3Q4Y-0006kE-Ie for bug-gnu-emacs@gnu.org; Sat, 14 Oct 2017 13:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Weiner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Oct 2017 17:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28620-submit@debbugs.gnu.org id=B28620.150800145725884 (code B ref 28620); Sat, 14 Oct 2017 17:18:02 +0000 Original-Received: (at 28620) by debbugs.gnu.org; 14 Oct 2017 17:17:37 +0000 Original-Received: from localhost ([127.0.0.1]:40464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3Q48-0006jP-To for submit@debbugs.gnu.org; Sat, 14 Oct 2017 13:17:37 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52425) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3Q47-0006jB-BY for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 13:17:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e3Q3y-0001PX-Vj for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 13:17:30 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3Q3y-0001PF-Rr for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 13:17:26 -0400 Original-Received: from mail-qk0-f169.google.com ([209.85.220.169]:51469) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1e3Q3y-0001ig-FJ for 28620@debbugs.gnu.org; Sat, 14 Oct 2017 13:17:26 -0400 Original-Received: by mail-qk0-f169.google.com with SMTP id 17so8428116qkq.8 for <28620@debbugs.gnu.org>; Sat, 14 Oct 2017 10:17:26 -0700 (PDT) X-Gm-Message-State: AMCzsaU73sO9Jy7bTlav+8Y3evvg9+KPFCNBwoV3Hd6hzKS0sKDczg/7 XQb0TkMe3iTjNW/0XE2lKpArXzlYWFaq0Bwk5Fc= X-Google-Smtp-Source: AOwi7QBVw1cGLvjksPfEmnHVllT55wzOxW+SZ2kwxRR0e37+i/qVB2OzP/SCFzXohYC4w2KT2SOEygwxxMe+5Lg9VEM= X-Received: by 10.55.12.130 with SMTP id 124mr7145855qkm.186.1508001445921; Sat, 14 Oct 2017 10:17:25 -0700 (PDT) Original-Received: by 10.237.34.225 with HTTP; Sat, 14 Oct 2017 10:16:55 -0700 (PDT) In-Reply-To: <59E1CC55.2090400@gmx.at> X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:138411 Archived-At: --001a114d6da08149f4055b84f226 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > > =E2=80=8BI 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. > > =E2=80=98mouse-drag-region=E2=80=99 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. =E2=80=8BOk, that indicates that drag-and-drop from Emacs to external appli= cations 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. =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > =E2=80=8BJust FYI, I am using the macOS window manager, not X, though a= s you > note, > =E2=80=8B=E2=80=8B > > it is an issue there too. > =E2=80=8B=E2=80=8B > > The application-level window managers must have a z-ordering for all > =E2=80=8B=E2=80=8B > > windows in order to be able to select and raise windows when they are > =E2=80=8B=E2=80=8B > > behind others. So you are saying that they don't publish this > information > =E2=80=8B=E2=80=8B > > in any useful way that Emacs can obtain, right? > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > All I can say is that when you nowadays try to obtain information on > =E2=80=8B=E2=80=8B > whether a window is really visible under X, chances are that you don't > =E2=80=8B=E2=80=8B > g > =E2=80=8B=E2=80=8B > e > =E2=80=8B=E2=80=8B > t > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > i > =E2=80=8B=E2=80=8B > t > =E2=80=8B=E2=80=8B > . =E2=80=8BEach window has a 'visible' attribute. Are you saying this is not accurate these days?=E2=80=8B =E2=80=8B=E2=80=8B=E2=80=8B > =E2=80=8B > Querying the z-order will only tell you something like "window > =E2=80=8B=E2=80=8B > Y cannot obscure window X because it's lower in the z-order". =E2=80=8BWe just want to know when given a screen position whether an Emacs= frame is topmost at that position or not.=E2=80=8B =E2=80=8B=E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > Part of the issue is that the macOS window manager uses click-to-focus, > so > =E2=80=8B=E2=80=8B > > the release event of the drag does not switch focus to the application > =E2=80=8B=E2=80=8B > > whose window the release falls upon. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > As Stefan already mentioned earlier: With a drag operation usually no > =E2=80=8B=E2=80=8B > 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. =E2=80=8B=E2=80=8B > > =E2=80=8B > > However, in drag-n-drop operations, > =E2=80=8B=E2=80=8B > > the window manager automatically switches focus to any compatible > =E2=80=8B=E2=80=8B > > application that the mouse moves over (after a delay) so that the right > =E2=80=8B=E2=80=8B > > application receives the drop (based on Z-order). > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > It's completely up to the window manager which polls the application(s) > =E2=80=8B=E2=80=8B > whether they are ready to receive the object to drop. Emacs is not > =E2=80=8B=E2=80=8B > involved in that process. It would be involved only to tell whether it > =E2=80=8B=E2=80=8B > would accept such a string when it's the target of a drop. =E2=80=8BI 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. =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > Mouse wheel events are also delivered to the topmost Z-order window > without > =E2=80=8B=E2=80=8B > > either raising the window or switching focus. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Mouse wheel events are completely different and highly window system > =E2=80=8B=E2=80=8B > dependent. Sometimes they get caught before Emacs sees them at all and > =E2=80=8B=E2=80=8B > get transformed to scroll bar thumb drag events to the owner of the > =E2=80=8B=E2=80=8B > scroll bar nearest to the mouse cursor at the time the wheel gets > =E2=80=8B=E2=80=8B > scrolled. =E2=80=8BAgain, I was just providing context of what might be possible base= d on other event handling that occurs already in Emacs under macOS.=E2=80=8B =E2=80=8B=E2=80=8B > > =E2=80=8B > =E2=80=8B=E2=80=8B > > So the window manager always knows where it should deliver > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > ... it never "knows". Some make better guesses and some make worse ... =E2=80=8BOn macOS the scroll wheel events seem to go to the right window 10= 0% of the time from what I have seen.=E2=80=8B =E2=80=8B=E2=80=8B > > =E2=80=8B > =E2=80=8B=E2=80=8B > > What would the pseudo-code > =E2=80=8B=E2=80=8B > > look like to check whether or not an Emacs frame was uppermost at the > point > =E2=80=8B=E2=80=8B > > of mouse release? > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > (1) =E2=80=98frame-list-z-order=E2=80=99 would have to be able to return = all windows on > =E2=80=8B=E2=80=8B > your system =E2=80=8BIs it likely we could build a multi-platform primitive =E2=80=8Bth= at would supply that information given what you have said? =E2=80=8B=E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > and (2) a function would be needed to get the attributes of > =E2=80=8B=E2=80=8B > those windows. =E2=80=8B2 seems straightforward. Bob =E2=80=8B=E2=80=8B --001a114d6da08149f4055b84f226 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Martin:
<= span style=3D"font-family:arial,sans-serif">
Thanks for commenting on this and sharing some o= f your extensive knowledge on window event handling and Emacs.
=

On Sat, Oct 14, 2017 at 4:35 AM, martin rudalics <rudalics@gmx.at> wrote:
> =E2=80=8BI think it is a feature that Emacs rece= ives an event for this but a defect
> that it can't distinguish when f2 is atop an external window or no= t and
> thus whether the event was actually directed at f2 or not.

 =E2=80=98mouse-drag-region=E2=80=99 is an Emacs internal function, so it= 9;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<= br> internal string or convert that string to some appropriate coding that
other applications understand.=C2=A0 Neither of these has been done yet and=
it will be non-trivial to do that for our various platforms.

=E2=80=8BOk, that indicates that drag-and-drop from Emacs to exter= nal applications is unlikely but it still leaves the issue of recognizing w= hether a drag release event maps to an Emacs frame or not (when the frame i= s covered by an external app's window).=C2=A0 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 rel= ease events.

I guess you are saying that Emacs drag events must star= t and end within Emacs frames.=C2=A0 I think about it a bit differently.=C2= =A0 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 stil= l register with Emacs (when the release occurs within the geometry of a fra= me but the frame is covered by another app's window), I think Emacs eve= nt handling should return different information when the release frame is n= ot the topmost OS-level window at the point of release.=C2=A0 Then handler = code could dispatch as necessary.

I already have Lisp code doing u= seful things with such information (presently, I have to adjust the drag re= lease event information).=C2=A0 So I know it would be helpful to have this = as default Emacs event reporting behavior.

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> =E2=80=8BJust FYI, I am using the m= acOS window manager, not X, though as you note,
=E2=80=8B=E2=80=8B
> it is an issue there too.
=E2=80=8B=E2=80=8B
> The application-level window manage= rs must have a z-ordering for all
=E2=80=8B=E2=80=8B
> windows in order to be able to sele= ct and raise windows when they are
=E2=80=8B=E2=80=8B
> behind others.=C2=A0 So you are say= ing that they don't publish this information
=E2=80=8B=E2=80=8B
> in any useful way that Emacs can ob= tain, right?
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
All I can say is that when you nowadays = try to obtain information on
=E2=80=8B=E2=80=8B
whether a window is really visible under= X, chances are that you don't
=E2=80=8B=E2=80=8B
g
=E2=80=8B=E2=80=8B
e=E2=80=8B=E2=80=8B
t
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
i
=E2=80=8B=E2=80=8B
t
=E2=80=8B=E2=80=8B
.

=E2=80=8BEach windo= w has a 'visible' attribute.=C2=A0 Are you saying this is not accur= ate these days?=E2=80=8B
=E2=80=8B=E2=80=8B=E2=80=8B
=E2=80=8B
=C2=A0 Querying the z-order = will only tell you something like "window
=E2=80=8B=E2=80=8B
Y cannot obscure window X because it'= ;s lower in the z-order".

=E2=80=8BWe ju= st want to know when given a screen position whether an Emacs frame is topm= ost at that position or not.=E2=80=8B
=E2=80=8B=E2=80=8B=E2=80=8B
=E2=80=8B=E2= =80=8B

=E2=80=8B=E2=80=8B
> Part of the issue i= s that the macOS window manager uses click-to-focus, so
=E2=80=8B=E2=80=8B
> the release event of the drag does = not switch focus to the application
=E2=80=8B=E2=80=8B
> whose window the release falls upon= .
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
As Stefan already mentioned earlier: Wit= h a drag operation usually no
=E2=80=8B=E2=80=8B
focus shifting occurs anyway.

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

=E2=80=8B=E2=80=8B

=E2=80=8B
> However, in drag-n-drop operations,
=E2=80=8B=E2=80=8B
> the window manager automatically sw= itches focus to any compatible
=E2=80=8B=E2=80=8B
> application that the mouse moves ov= er (after a delay) so that the right
=E2=80=8B=E2=80=8B
> application receives the drop (base= d on Z-order).
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
It's completely up to the window man= ager which polls the application(s)
=E2=80=8B=E2=80=8B
whether they are ready to receive the ob= ject to drop.=C2=A0 Emacs is not
=E2=80=8B=E2=80=8B
involved in that process.=C2=A0 It would= be involved only to tell whether it
=E2=80=8B=E2=80=8B
would accept such a string when it's= the target of a drop.

=E2=80=8BI understand that.= =C2=A0 I was just noting that there is an example of a drag release event h= andler that selects the window of release as a standard part of its operati= on.

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> Mouse wheel events are also deliver= ed to the topmost Z-order window without
=E2=80=8B=E2=80=8B
> either raising the window or switch= ing focus.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
Mouse wheel events are completely differ= ent and highly window system
=E2=80=8B=E2=80=8B
dependent.=C2=A0 Sometimes they get caug= ht before Emacs sees them at all and
=E2=80=8B=E2=80=8B
get transformed to scroll bar thumb drag= events to the owner of the
=E2=80=8B=E2=80=8B
scroll bar nearest to the mouse cursor a= t the time the wheel gets
=E2=80=8B=E2=80=8B
scrolled.

=E2=80= =8BAgain, I was just providing context of what might be possible based on o= ther event handling that occurs already in Emacs under macOS.=E2=80=8B
=E2=80=8B= =E2=80=8B

=E2=80=8B
=E2=80=8B=E2=80=8B
> So the wi= ndow manager always knows where it should deliver
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
... it never "knows".=C2=A0 So= me make better guesses and some make worse ...

<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2= =80=8BOn macOS the scroll wheel events seem to go to the right window 100% = of the time from what I have seen.=E2=80=8B

=E2=80=8B=E2=80=8B

=E2=80=8B
=E2=80=8B=E2=80=8B
> What woul= d the pseudo-code
=E2=80=8B=E2=80=8B
> look like to check whether or not a= n Emacs frame was uppermost at the point
=E2=80=8B=E2=80=8B
> of mouse release?
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
(1) =E2=80=98frame-list-z-order=E2=80=99= would have to be able to return all windows on
=E2=80=8B=E2=80=8B
your system

<= div>
= =E2=80=8BIs it likely we could build a multi-platform primitive =E2=80=8Bth= at would supply that information given what you have said?
=E2=80=8B=E2= =80=8B=E2=80=8B
=E2= =80=8B=E2=80=8B
and (2) a function would be needed to get the attribut= es of
=E2=80=8B=E2=80=8B
those windows.

= =E2=80=8B2 seems straightforward.

Bob
=E2=80=8B=E2=80=8B
--001a114d6da08149f4055b84f226--