From: Alan Third <alan@idiocy.org>
To: rswgnu@gmail.com
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 19:59:00 +0100 [thread overview]
Message-ID: <20171004185900.GA52514@breton.holly.idiocy.org> (raw)
In-Reply-To: <CA+OMD9jXzeenG10d28BfkJy_DgF=1aQUj7FdHOBL4d9BhTy7kA@mail.gmail.com>
On Wed, Oct 04, 2017 at 01:26:18PM -0400, Robert Weiner wrote:
> 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 NSEvent is delivered to the EmacsView belonging to the frame where
the drag was initiated. I don’t think there’s anything we can do to
change that.
> > 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).
I don’t believe it’s possible. As I described before we’d have to do
something like:
[...] get a list of NSWindows, iterate over them to find out which
one the mouse pointer is over, convert that NSWindow back to an Emacs
frame, and [return it].
> > 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.
But which behaviour? I can’t work out exactly what we’re talking about
here. Are you trying to get cross‐frame dragging working or are you
genuinely concerned that Emacs doesn’t receive a click event when the
frame is selected using the mouse? These seem like two different
things to me.
> > 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.
Fns_frame_list_z_order in nsfns.m does some of what’s described
above... But...
It looks like there’s maybe a neater way to get the current frame
under the mouse...
Lisp_Object frame = Qnil;
NSWindow *w = [NSApp windowWithWindowNumber:
[NSWindow windowNumberAtPoint:[NSEvent mouseLocation]
belowWindowWithWindowNumber:0]];
if (w != nil)
XSETFRAME (frame, ((EmacsView *)[w delegate])->emacsframe);
I’ve not tested this, so it may not work at all. Note that [NSEvent
mouseLocation] returns an NSPoint indicating where the mouse is *right
now*. It would probably be more sensible to use any co‐ordinates
provided by the event itself.
--
Alan Third
next prev parent reply other threads:[~2017-10-04 18:59 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
2017-10-04 18:59 ` Alan Third [this message]
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=20171004185900.GA52514@breton.holly.idiocy.org \
--to=alan@idiocy.org \
--cc=28620@debbugs.gnu.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.