[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#28620: Interact directly on Emacs bug#28620: mouse drag event record
From: |
Alan Third |
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 |
User-agent: |
Mutt/1.9.0 (2017-09-02) |
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