From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.devel Subject: Re: Possible Bug: Mouse drag event records wrong window for release when crossing frames Date: Fri, 29 Sep 2017 09:03:59 -0400 Message-ID: References: <59CB5D45.9070603@gmx.at> <59CE058D.3010607@gmx.at> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c0600bc54cf48055a53aa81" X-Trace: blaine.gmane.org 1506690292 31356 195.159.176.226 (29 Sep 2017 13:04:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 29 Sep 2017 13:04:52 +0000 (UTC) Cc: emacs-devel To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 29 15:04:46 2017 Return-path: Envelope-to: ged-emacs-devel@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 1dxuyC-0007fO-RA for ged-emacs-devel@m.gmane.org; Fri, 29 Sep 2017 15:04:45 +0200 Original-Received: from localhost ([::1]:35351 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxuyK-0007eB-94 for ged-emacs-devel@m.gmane.org; Fri, 29 Sep 2017 09:04:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49922) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxuy2-0007dz-7D for emacs-devel@gnu.org; Fri, 29 Sep 2017 09:04:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dxuxz-0003u3-1x for emacs-devel@gnu.org; Fri, 29 Sep 2017 09:04:34 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxuxy-0003tu-V8 for emacs-devel@gnu.org; Fri, 29 Sep 2017 09:04:30 -0400 Original-Received: from mail-qk0-f169.google.com ([209.85.220.169]:56963) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dxuxy-0006dk-Mz for emacs-devel@gnu.org; Fri, 29 Sep 2017 09:04:30 -0400 Original-Received: by mail-qk0-f169.google.com with SMTP id g128so1066466qke.13 for ; Fri, 29 Sep 2017 06:04:30 -0700 (PDT) X-Gm-Message-State: AMCzsaWFyfxWcbX9jeik0ndUy2arAr6/cGfvXfY+c7EQaDS3pHdsg24M 280bWWD2zVltnZeCoS/Kp+EYVOvh30T2NOXfmhQ= X-Google-Smtp-Source: AOwi7QACnkOaiyVP7d/lyl4PE5z/lky6tmVpnvNkNXwPKQhP7fTyd9dZS0Iv1jZYP3hSh0JGQLPassCM9Uuv4/5wPRE= X-Received: by 10.55.161.85 with SMTP id k82mr3109586qke.156.1506690270019; Fri, 29 Sep 2017 06:04:30 -0700 (PDT) Original-Received: by 10.237.34.225 with HTTP; Fri, 29 Sep 2017 06:03:59 -0700 (PDT) In-Reply-To: <59CE058D.3010607@gmx.at> X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:218897 Archived-At: --94eb2c0600bc54cf48055a53aa81 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 29, 2017 at 4:34 AM, martin rudalics wrote: > > =E2=80=8BThe behavior is the same either way. It is definitely a bug i= n Emacs > 25.2 > > and 25.3 as I have confirmed it on both MacOS and Windows 7 using just > > default mouse-1 =E2=80=8Bdrags between frames. > > Do you mean that earlier Emacsen behave differently in this regard? =E2=80=8BNo, just that I tested only with those versions. =E2=80=8B > >> The start event seems to look OK. As for the end event, an X-coordina= te > >> of -1373 does not look reasonable. > > > > > > =E2=80=8BRight. Is a negative value ever valid in this context? > > I think so. For example if you want to move your frame to that position > on the screen. =E2=80=8BOk. =E2=80=8B > > My claim is that if you put 2 frames on screen (start with > non-overlapping) > > and drag mouse-1 from the text area of one to the second, that the drag > > event generated upon the release of mouse-1 will contain frame1 rather > than > > frame2 (where the release happened).=E2=80=8B > > IIUC Emacs never was able to do that. Mouse dragging events so far make > sense only for the one-frame case. =E2=80=8BThis needs to be fixed as it is a very natural gesture to move between frames. For the text area, this is moving between windows which just happen to occupy different frames. =E2=80=8B > What you want involves much more > trickery: If you have two target frames covering the same screen > position, which one would you choose when releasing the mouse at that > position? Probably the one higher in the z-order. =E2=80=8BYes. It may be easier to think of it in terms of the window of release rather than the frame=E2=80=8B as one will almost always need to know the window as well. =E2=80=8B=E2=80=8B One initial way to decrease the complexity is to make this work only when both the depress and release commands set the selected window. Then the posn- functions would have a unique window to report. =E2=80=8B=E2=80=8B > But only Emacs 26 > =E2=80=8B=E2=80=8B > can handle that and we would have to write routines to do it. =E2=80=8BOk . > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Or > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > the one that gets focus during mouse tracking because your window > =E2=80=8B=E2=80=8B > manager has some sort of focus-follows-mouse installed? Then you would > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > have to query the focus when you release the mouse. Non-trivial. =E2=80=8BSee above. Thanks much for the feedback. I can say that if this is implemented, it will lead to improved user interfaces and faster inter-frame control in many instances. Bob =E2=80=8B --94eb2c0600bc54cf48055a53aa81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Sep 29, 2= 017 at 4:34 AM, martin rudalics <rudalics@gmx.at> wrote:
> =E2=80=8BThe behavior is th= e same either way.=C2=A0 It is definitely a bug in Emacs 25.2
> and 25.3 as I have confirmed it on both MacOS and Windows 7 using just=
> default mouse-1 =E2=80=8Bdrags between frames.

 Do you mean that earlier Emacsen behave differently in this regard?

=E2=80=8BNo, just that I tested only with those versions.
= =E2=80=8B
>> The start event seems to look OK.=C2=A0 As for the end event, an X= -coordinate
>> of -1373 does not look reasonable.
>
>
> =E2=80=8BRight.=C2=A0 Is a negative value ever valid in this context?<= br>
I think so.=C2=A0 For example if you want to move your frame to that positi= on
on the screen.

=E2=80=8BOk.
=E2=80=8B
> My claim is that if you put 2 frames on s= creen (start with non-overlapping)
> and drag mouse-1 from the text area of one to the second, that the dra= g
> event generated upon the release of mouse-1 will contain frame1 rather= than
> frame2 (where the release happened).=E2=80=8B

 IIUC Emacs never was able to do that.=C2=A0 Mouse dragging events so far ma= ke
sense only for the one-frame case.

=E2=80=8BThis nee= ds to be fixed as it is a very natural gesture to
move between frames.=C2= =A0 For the text area, this is moving
between windows which just happen to= occupy different frames.
=E2=80=8B
= =C2=A0 What you want involves much more
trickery: If you have two target frames covering the same screen
position, which one would you choose when releasing the mouse at that
position?=C2=A0 Probably the one higher in the z-order.
=E2=80=8BYes.=C2=A0 It may be easier to think of it in terms of the win= dow
of release rather than the frame=E2=80=8B as one will almost always
n= eed to know the window as well.
=E2=80=8B=E2=80=8B
One initial way t= o decrease the complexity is to make this work
only when both the depress = and release commands set the selected
window.=C2=A0 Then the posn- f= unctions would have a unique window to
report.

=E2=80=8B=E2=80=8B
=C2=A0 But only Emacs 26<= br>
=E2=80=8B=E2=80=8B
can handle that and we would have to wri= te routines to do it.

=E2=80=8BOk
.
=E2=80=8B=E2=80=8B
=C2=A0
=E2=80=8B=E2=80=8B
Or
=E2=80=8B=E2=80=8B
= =E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2= =80=8B=E2=80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
the one that gets focus during mouse tra= cking because your window
=E2=80=8B=E2=80=8B
manager has some sort of focus-follows-m= ouse installed?=C2=A0 Then you would
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2= =80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80= =8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B= =E2=80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
have to query the focus when you release= the mouse.=C2=A0 Non-trivial.

=E2=80=8BSee above.
=
Thanks much for the feedback.=C2=A0 I can say that if this is
implem= ented, it will lead to improved user interfaces and
faster inter-frame con= trol in many instances.

Bob
=E2=80=8B
--94eb2c0600bc54cf48055a53aa81--