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: Wed, 4 Oct 2017 13:26:18 -0400 Message-ID: References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <20171003224017.GA51637@breton.holly.idiocy.org> <20171004163048.GA52414@breton.holly.idiocy.org> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11405bcea581eb055abbe968" X-Trace: blaine.gmane.org 1507138037 19379 195.159.176.226 (4 Oct 2017 17:27:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Oct 2017 17:27:17 +0000 (UTC) Cc: 28620@debbugs.gnu.org To: Alan Third Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 04 19:27:10 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 1dznRp-0003aK-D4 for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Oct 2017 19:27:05 +0200 Original-Received: from localhost ([::1]:36232 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dznRw-0000uq-G2 for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Oct 2017 13:27:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dznRq-0000uf-4y for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2017 13:27:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dznRm-0005bp-PW for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2017 13:27:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40478) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dznRm-0005bU-Kw for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2017 13:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dznRm-0007uf-CF for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2017 13:27: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: Wed, 04 Oct 2017 17:27: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.150713802130411 (code B ref 28620); Wed, 04 Oct 2017 17:27:02 +0000 Original-Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 17:27:01 +0000 Original-Received: from localhost ([127.0.0.1]:49159 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dznRl-0007uP-1x for submit@debbugs.gnu.org; Wed, 04 Oct 2017 13:27:01 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54081) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dznRi-0007uA-FS for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 13:26:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dznRa-0005Wk-0p for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 13:26:53 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33008) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dznRZ-0005Wc-Sz for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 13:26:49 -0400 Original-Received: from mail-qt0-f178.google.com ([209.85.216.178]:53721) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dznRZ-0006LD-Cg for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 13:26:49 -0400 Original-Received: by mail-qt0-f178.google.com with SMTP id 47so20585291qts.10 for <28620@debbugs.gnu.org>; Wed, 04 Oct 2017 10:26:49 -0700 (PDT) X-Gm-Message-State: AMCzsaVnoHrpegU4jC7wo6gEwiQRbxWlF2AmJJVL6ksGgohKNcQpzpz+ MLgT5MyLlaMrc6Yjv3rP6v7an7AlhoWye9XQ0Jw= X-Google-Smtp-Source: AOwi7QCicMr+ISpzwx0y5z4V6BStQUDvr6lhRiWapCstPTKQLNibE2PB53zKKtAzfNa+UE9V60lkoGBDnN1Ll9I0zEQ= X-Received: by 10.200.44.118 with SMTP id e51mr12545752qta.171.1507138008873; Wed, 04 Oct 2017 10:26:48 -0700 (PDT) Original-Received: by 10.237.34.225 with HTTP; Wed, 4 Oct 2017 10:26:18 -0700 (PDT) In-Reply-To: <20171004163048.GA52414@breton.holly.idiocy.org> 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:137911 Archived-At: --001a11405bcea581eb055abbe968 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 4, 2017 at 12:30 PM, Alan Third wrote: > On Tue, Oct 03, 2017 at 08:15:53PM -0400, Robert Weiner wrote: > > On Tue, Oct 3, 2017 at 6:40 PM, Alan Third wrote: > > > As far as I can tell ns_mouse_position returns the frame stored in > > > dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDown, > however: > > > > > > If the user clicks a view that isn=E2=80=99t in the key window, b= y default > > > the window is brought forward and made key, but the mouse event i= s > > > not dispatched. > > > > > > > =E2=80=8BWhat does "the mouse event is not dispatched mean"? Does it m= ean Emacs > > never sees the event? Maybe Emacs sees only that the window has been > > selected by the window manager and based on that switches to the select= ed > > window of the frame? > > Precisely that. > =E2=80=8BSo how is it that Emacs processes a drag event when the mouse butt= on is released in the new frame if it never sees the mouseUp (drag release) event?=E2=80=8B If I drag across frames, on mouseUp, the key binding assoc= iated with mouseUp (mouse-1 as opposed to down-mouse-1 is run). =E2=80=8B=E2=80=8B > > > =E2=80=8BThe mouse wheel code manages to scroll the proper window that = the mouse > is > > over, even across overlapping frames where the window the mouse is over > is > > in a frame that is partially behind another frame. And this happens > > without without any click events. This could be utilized in the click > > event code to get this right somehow. > > The mouse wheel code is also handled in mouseDown, the difference is > that macOS always sends the mouse wheel event to the emacs frame under > the mouse pointer, whereas the mouse click event is not sent when the > frame is not already key (i.e. selected). > =E2=80=8BCan you show some sample code that would make macOS send the mouse= drag release event to the frame under the mouse pointer just as the scroll wheel code does. I have looked at this mouseUp code in nsterm.m but cannot get it to do this. I have managed to inject a focus in event to the mouseUp=E2= =80=8B function and make its event frame the key frame (selected frame) but its event frame is the wrong one (it always has the frame of the mouseDown event). =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > AFAICT Emacs does the right thing here, exactly the same thing as > =E2=80=8B=E2=80=8B > every other macOS app. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B =E2=80=8BAs Eli noted, this does not happen under MS Windows. I want to ha= ve behavior that allows for drags across frames. The present code does not, so whether it is consistent with Mac UI guidelines, it is not useful for that purpose. I would like your help in figuring out how to enable such behavior as you seem to understand the macOS event flow well. =E2=80=8B=E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > It looks like the EV_TRAILER macro call at the end of the nsterm.c > =E2=80=8B=E2=80=8B > > mouseDown function (which is also called by mouseUp) sets the frame use= d > =E2=80=8B=E2=80=8B > > for mouse button down, up and scroll wheel events from the variable > =E2=80=8B=E2=80=8B > > emacsframe. Somehow the value of emacsframe must be set differently fo= r > =E2=80=8B=E2=80=8B > > mouse up events than it is for mouse wheel events since they end up wit= h > =E2=80=8B=E2=80=8B > > different frames for the same mouse positions. > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > There=E2=80=99s nothing fancy here, emacsframe is an instance variable > =E2=80=8B=E2=80=8B > associated with the EmacsView that macOS sends the mouse event to. =E2=80=8BSo show me how and where I could set that variable to the frame of= the mouse position at the point of mouseUp=E2=80=8B and I will test it and let = people know if it works. Thanks, Bob --001a11405bcea581eb055abbe968 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 4, 20= 17 at 12:30 PM, Alan Third <al= an@idiocy.org> w= rote:
On Tue, Oct 03, 2017 at 08= :15:53PM -0400, Robert Weiner wrote:
> On Tue, Oct 3, 2017 at 6:40 PM, Alan Third <alan@idiocy.org> wrote:
> > As far as I can tell ns_mouse_position re= turns the frame stored in
> > dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDow= n, however:
> >
> >=C2=A0 =C2=A0 =C2=A0If the user clicks a view that isn=E2=80=99t i= n the key window, by default
> >=C2=A0 =C2=A0 =C2=A0the window is brought forward and made key, bu= t the mouse event is
> >=C2=A0 =C2=A0 =C2=A0not dispatched.
> >
>
> =E2=80=8BWhat does "the mouse event is not dispatched mean"?= =C2=A0 Does it mean Emacs
> never sees the event?=C2=A0 Maybe Emacs sees only that the window has = been
> selected by the window manager and based on that switches to the selec= ted
> window of the frame?

Precisely that.

=E2=80=8BSo how is it tha= t Emacs processes a drag event when the mouse button is released in the new= frame if it never sees the mouseUp (drag release) event?=E2=80=8B=C2=A0 If= I drag across frames, on mouseUp, the key binding associated with mouseUp = (mouse-1 as opposed to down-mouse-1 is run).

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

> =E2=80=8BThe mouse wheel code manages to scroll the proper window that= the mouse is
> over, even across overlapping frames where the window the mouse is ove= r is
> in a frame that is partially behind another frame.=C2=A0 And this happ= ens
> without without any click events.=C2=A0 This could be utilized in the = click
> event code to get this right somehow.

The mouse wheel code is also handled in mouseDown, the difference is=
that macOS always sends the mouse wheel event to the emacs frame under
the mouse pointer, whereas the mouse click event is not sent when the
frame is not already key (i.e. selected).

=E2=80= =8BCan you show some sample code that would make macOS send the mouse drag = release event to the frame under the mouse pointer just as the scroll wheel= code does.=C2=A0 I have looked at this mouseUp code in nsterm.m but cannot= get it to do this.=C2=A0 I have managed to inject a focus in event to the = mouseUp=E2=80=8B function and make its event frame the key frame (selected = frame) but its event frame is the wrong one (it always has the frame of the= mouseDown event).

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

=E2=80=8B=E2=80=8B
AFAICT Emacs does the right thing here, = exactly the same thing as
=E2=80=8B=E2=80=8B
every other macOS app.
=E2=80= =8B=E2=80=8B

=E2=80=8B=E2=80=8B
=E2=80=8BAs Eli no= ted, this does not happen under MS Windows.=C2=A0 I want to have behavior t= hat allows for drags across frames.=C2=A0 The present code does not, so whe= ther it is consistent with Mac UI guidelines, it is not useful for that pur= pose.=C2=A0 I would like your help in figuring out how to enable such behav= ior as you seem to understand the macOS event flow well.
=E2=80=8B=E2=80= =8B=E2=80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> It looks like the EV_TRAILER macro = call at the end of the nsterm.c
=E2=80=8B=E2=80=8B
> mouseDown function (which is also c= alled by mouseUp) sets the frame used
=E2=80=8B=E2=80=8B
> for mouse button down, up and scrol= l wheel events from the variable
=E2=80=8B=E2=80=8B
> emacsframe.=C2=A0 Somehow the value= of emacsframe must be set differently for
=E2=80=8B=E2=80=8B
> mouse up events than it is for mous= e wheel events since they end up with
=E2=80=8B=E2=80=8B
> different frames for the same mouse= positions.
=E2=80=8B=E2=80=8B=C2=A0
=E2=80=8B=E2=80=8B
There=E2=80=99s nothing fancy her= e, emacsframe is an instance variable
=E2=80=8B=E2=80=8B
associated with the EmacsView that macOS= sends the mouse event to.

=E2=80=8BSo show me how a= nd where I could set that variable to the frame of the mouse position at th= e point of mouseUp=E2=80=8B and I will test it and let people know if it wo= rks.

Thanks,

Bob


--001a11405bcea581eb055abbe968--