From: Robert Weiner <rsw@gnu.org>
To: Alan Third <alan@idiocy.org>
Cc: 28620@debbugs.gnu.org
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 [thread overview]
Message-ID: <CA+OMD9jXzeenG10d28BfkJy_DgF=1aQUj7FdHOBL4d9BhTy7kA@mail.gmail.com> (raw)
In-Reply-To: <20171004163048.GA52414@breton.holly.idiocy.org>
[-- Attachment #1: Type: text/plain, Size: 3642 bytes --]
On Wed, Oct 4, 2017 at 12:30 PM, Alan Third <alan@idiocy.org> 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 <alan@idiocy.org> 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’t in the key window, by default
> > > the window is brought forward and made key, but the mouse event is
> > > not dispatched.
> > >
> >
> > What does "the mouse event is not dispatched mean"? Does it mean 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 selected
> > window of the frame?
>
> Precisely that.
>
So how is it that Emacs processes a drag event when the mouse button is
released in the new frame if it never sees the mouseUp (drag release)
event? If I drag across frames, on mouseUp, the key binding associated
with mouseUp (mouse-1 as opposed to down-mouse-1 is run).
>
> > The 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).
>
Can 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
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).
>
>
> AFAICT Emacs does the right thing here, exactly the same thing as
>
> every other macOS app.
>
>
>
As Eli noted, this does not happen under MS Windows. I want to have
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.
>
>
>
> > It looks like the EV_TRAILER macro call at the end of the nsterm.c
>
> > mouseDown function (which is also called by mouseUp) sets the frame used
>
> > for mouse button down, up and scroll wheel events from the variable
>
> > emacsframe. Somehow the value of emacsframe must be set differently for
>
> > mouse up events than it is for mouse wheel events since they end up with
>
> > different frames for the same mouse positions.
>
>
> There’s nothing fancy here, emacsframe is an instance variable
>
> associated with the EmacsView that macOS sends the mouse event to.
So show me how and where I could set that variable to the frame of the
mouse position at the point of mouseUp and I will test it and let people
know if it works.
Thanks,
Bob
[-- Attachment #2: Type: text/html, Size: 7180 bytes --]
next prev parent reply other threads:[~2017-10-04 17:26 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@mail.gmail.com>
[not found] ` <83wp4e3nvx.fsf@gnu.org>
[not found] ` <DCD76686-AED1-4D1B-BF28-CAA693633E07@gmail.com>
[not found] ` <8360bx340d.fsf@gnu.org>
[not found] ` <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@mail.gmail.com>
[not found] ` <8360bw19es.fsf@gnu.org>
[not found] ` <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@mail.gmail.com>
2017-10-03 18:21 ` bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window Robert Weiner
2017-10-03 18:42 ` Eli Zaretskii
2017-10-03 18:53 ` Robert Weiner
2017-10-03 22:40 ` Alan Third
2017-10-04 0:15 ` Robert Weiner
2017-10-04 16:30 ` Alan Third
2017-10-04 17:26 ` Robert Weiner [this message]
2017-10-04 18:59 ` Alan Third
2017-10-04 19:30 ` Robert Weiner
2017-10-04 20:11 ` Robert Weiner
2017-10-04 20:07 ` Robert Weiner
2017-10-04 22:09 ` Alan Third
2017-10-05 0:38 ` Robert Weiner
[not found] ` <83vajwytja.fsf@gnu.org>
[not found] ` <CA+OMD9gtwbg4gZzFryWCteN-gHuwvvqTYhVf2WUmpznZ9jo+Ng@mail.gmail.com>
[not found] ` <83poa4yqyq.fsf@gnu.org>
[not found] ` <CA+OMD9gM_3qgioX_RhhDHWF9GYA7=6++Hq5im2nwcwtdKLyDnA@mail.gmail.com>
[not found] ` <CA+OMD9g5dX8Dg92F1pRgYKt3j0yyg=8rBOpSc5SePPiodFnOWA@mail.gmail.com>
[not found] ` <83376qouoj.fsf@gnu.org>
[not found] ` <CA+OMD9hi52ZgCWFTSFPBEu2tOpF12kvHqpu8p4oi-f6jPdw2bA@mail.gmail.com>
2017-10-11 18:49 ` Robert Weiner
2017-10-12 1:35 ` Robert Weiner
2017-10-12 1:47 ` Robert Weiner
2017-10-12 8:05 ` martin rudalics
2017-10-12 13:08 ` Robert Weiner
2017-10-14 8:35 ` martin rudalics
2017-10-14 17:16 ` Robert Weiner
2017-10-14 18:47 ` Robert Weiner
2017-10-15 3:31 ` Robert Weiner
2017-10-15 9:40 ` martin rudalics
2017-10-16 16:31 ` Robert Weiner
2017-10-17 8:57 ` martin rudalics
2017-10-19 18:32 ` Robert Weiner
2017-10-20 7:55 ` martin rudalics
2017-10-20 14:26 ` Robert Weiner
2017-10-21 8:05 ` martin rudalics
2017-10-21 18:05 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+OMD9jXzeenG10d28BfkJy_DgF=1aQUj7FdHOBL4d9BhTy7kA@mail.gmail.com' \
--to=rsw@gnu.org \
--cc=28620@debbugs.gnu.org \
--cc=alan@idiocy.org \
--cc=rswgnu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.