bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

Using the latest Emacs26 built from master on MacOS Sierra using the macOS
window system, I see the following if I have two frames: f1 and f2.

I start with the mouse within a window of f1 and selected frame of f1;
(mouse-position) also reports f1.

I click mouse-1 in an Emacs window of f2 and leave it there.
  (selected-frame) is now f2
  macOS window manager highlights f2 as active window
  (frame-focus) returns nil
  (mouse-position) reports a frame of f1       <<< WRONG


I click mouse-1 again in the same Emacs window of f2.
  (selected-frame) is still f2
  macOS window manager highlights f2 as active window
  (frame-focus) returns nil
  (mouse-position) now reports a frame of f2

This happens consistently in testing.  This must be a bug in mouse-position
for macOS, right?  Why would (mouse-position) still report f1 when f2 is
the selected frame?  Maybe this is why I am seeing the wrong frame on drag
releases too.

If anyone else could confirm this and whether it happens on other window
systems that use a mouse click to select windows, that would be helpful.

Bob

​​
​​

[-- Attachment #2: Type: text/html, Size: 3048 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Eli Zaretskii]

> From: Robert Weiner <rsw@gnu.org>
> Date: Tue, 3 Oct 2017 14:21:43 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>
> 
> I start with the mouse within a window of f1 and selected frame of f1; (mouse-position) also reports f1.
> 
> I click mouse-1 in an Emacs window of f2 and leave it there.
> (selected-frame) is now f2
> macOS window manager highlights f2 as active window
> (frame-focus) returns nil
> (mouse-position) reports a frame of f1 <<< WRONG

Sounds like something that's macOS specific.  At least on MS-Windows I
cannot reproduce this: mouse-position returns the correct frame.

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

On Tue, Oct 3, 2017 at 2:42 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Robert Weiner <rsw@gnu.org>
> > Date: Tue, 3 Oct 2017 14:21:43 -0400
> > Cc: Eli Zaretskii <eliz@gnu.org>
> >
> > I start with the mouse within a window of f1 and selected frame of f1;
> (mouse-position) also reports f1.
> >
> > I click mouse-1 in an Emacs window of f2 and leave it there.
> > (selected-frame) is now f2
> > macOS window manager highlights f2 as active window
> > (frame-focus) returns nil
> > (mouse-position) reports a frame of f1 <<< WRONG
>
> Sounds like something that's macOS specific.  At least on MS-Windows I
> cannot reproduce this: mouse-position returns the correct frame.
>

​Ok, that is good to know.  Is there a go to person for the Mac-specific
windowing code to check on this with?

Could someone check when running X with a click-for-focus window manager
setting and see what happens there?

Bob

[-- Attachment #2: Type: text/html, Size: 2052 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Alan Third]

On Tue, Oct 03, 2017 at 02:21:43PM -0400, Robert Weiner wrote:
> This happens consistently in testing.  This must be a bug in mouse-position
> for macOS, right?  Why would (mouse-position) still report f1 when f2 is
> the selected frame?  Maybe this is why I am seeing the wrong frame on drag
> releases too.

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.

        https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/EventOverview/HandlingMouseEvents/HandlingMouseEvents.html

My guess is that ns_mouse_position needs to 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 set *fp to it before
returning.

That way it should return the frame the mouse is over, rather than the
last one that received a click event.

I’m not sure what happens if the mouse isn’t over an emacs frame...
Does it just return *fp unchanged?
-- 
Alan Third

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]

On Tue, Oct 3, 2017 at 6:40 PM, Alan Third <alan@idiocy.org> wrote:

> On Tue, Oct 03, 2017 at 02:21:43PM -0400, Robert Weiner wrote:
> > This happens consistently in testing.  This must be a bug in
> mouse-position
> > for macOS, right?  Why would (mouse-position) still report f1 when f2 is
> > the selected frame?  Maybe this is why I am seeing the wrong frame on
> drag
> > releases too.
>
> 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?

> ​​
>
> ​​
>         https://developer.apple.com/library/content/documentation/
> Cocoa/Conceptual/EventOverview/HandlingMouseEvents/
> HandlingMouseEvents.html
> ​​
>
> ​​
> My guess is that ns_mouse_position needs to 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 set *fp to it before
> ​​
> returning.
>

​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.

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.

Bob

[-- Attachment #2: Type: text/html, Size: 4181 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Alan Third]

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.

> ​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).

AFAICT Emacs does the right thing here, exactly the same thing as
every other macOS app.

> 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.

-- 
Alan Third

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- 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 --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Alan Third]

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

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 6021 bytes --]

Hi Alan:

Thanks for your thoughts on this.

On Wed, Oct 4, 2017 at 2:59 PM, Alan Third <alan@idiocy.org> wrote:

> On Wed, Oct 04, 2017 at 01:26:18PM -0400, Robert Weiner wrote:
>
> > ​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.
>

​So you are saying that only one NSEvent is delivered to Emacs for both the
press and release of a drag that crosses frames?
And that Emacs internally internally recognizes both the press and release
of the mouse button and fires their respective key bindings but they both
share the location from that one NSEvent?

If so, why can't the nsterm.m mouseUp (release) handler synthesize an
NSEvent based on the current mouse position that is run prior to invoking
the keybinding for mouseUp?

​​
>
> ​​
> > > The mouse wheel code is also handled in
> ​​
> mouseDown, the difference is
> ​​
> > > that macOS always sends the mouse whe
> ​​
> el event to the emacs frame under
> ​​
> > > the mouse pointer, whereas the mouse cli
> ​​
> ck event is not sent when the
> ​​
> > > frame is not already key (i.e. selected).
> ​​
>
> ​​
​Ok, I understand that now.​
​​​

> ​
> > ​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
> ​​
> >
> ​​
> ​​
> c
> ​​
> o
> ​​
> d
> ​​
> e
> ​​
> ​​
> d
> ​​
> o
> ​​
> e
> ​​
> s
> ​​
> .
> ​
>
> ​​
>
> ​​
> 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 just tested under MS Windows 7 with Emacs 25 and saw the same behavior
as on the Mac (mouse-1 drag between frames yields a release event with the
depress frame rather than the release frame).  I'll have to talk to Eli
about this.
​

> ​​
>   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 su
> ​​
> ch
> ​​
> > behavior as you seem to understand the macOS event flow well.
> ​​
>
> ​​
>
> ​​
> But which behaviour? I can’t work out exactly what we’re talking ab
> ​​
> out
> ​​
> here. Are you trying to get cross‐frame dragging working


​Yes.​

​​
> 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.
>

​I want to work around that if possible.  The fact that Emacs can dispatch
on the mouseUp​ event tells me that we just need to determine the proper
window of mouse position at that point and use that instead of the frame
the Mac window system provides.

> ​​
>
> ​​
> > > 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.
> ​​
>
> F
> ​​
> ns_frame_list_z_order in nsfns.m does some of what’s described
> a
> ​​
> bove... 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.
>

If the coordinates represent the location of the mouseUp event rather than
mouseDown (of which I'm not sure), then why couldn't the frame differ as
well when we have the right functionality together?  Let me see if I can
test with mouseLocation first.

I would suggest that the (mouse-position) function should always return the
uppermost Z-ordered frame at point, even though it fails to do that now.

Bob

[-- Attachment #2: Type: text/html, Size: 18047 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

On Wed, Oct 4, 2017 at 3:30 PM, Robert Weiner <rsw@gnu.org> wrote:

> Hi Alan:
>
>>
>> ​​
>> 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);
>>
>
​As is, this didn't seem to have any effect.

Bob
​

[-- Attachment #2: Type: text/html, Size: 2354 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

On Wed, Oct 4, 2017 at 2:59 PM, Alan Third <alan@idiocy.org> wrote:

>
> 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);
>
>
The ​mouseDown​ function (called by the various mouseUp functions) uses
`emacsframe' to set the appropriate frame.
How does the above modify emacsframe?  Doesn't XSETFRAME just set the value
of the local `frame'?

Bob

[-- Attachment #2: Type: text/html, Size: 1694 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Alan Third]

On Wed, Oct 04, 2017 at 04:07:56PM -0400, Robert Weiner wrote:
> On Wed, Oct 4, 2017 at 2:59 PM, Alan Third <alan@idiocy.org> wrote:
> 
> >
> > 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);
> >
> >
> The ​mouseDown​ function (called by the various mouseUp functions) uses
> `emacsframe' to set the appropriate frame.
> How does the above modify emacsframe?  Doesn't XSETFRAME just set the value
> of the local `frame'?

Yes. You can’t modify emacsframe because it’s an instance variable.
You’ll need to modify whatever is using it to set the frame in the
emacs event.

So, assuming the code you’re modifying is calling EV_TRAILER, for now,
replace the call to EV_TRAILER with it’s contents:

    XSETFRAME (emacs_event->frame_or_window, emacsframe);
    EV_TRAILER2 (e);

and work from there.

-- 
Alan Third

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

On Wed, Oct 4, 2017 at 6:09 PM, Alan Third <alan@idiocy.org> wrote:

>
> Yes. You can’t modify emacsframe because it’s an instance variable.
> You’ll need to modify whatever is using it to set the frame in the
> emacs event.
>
> So, assuming the code you’re modifying is calling EV_TRAILER, for now,
> replace the call to EV_TRAILER with it’s contents:
>
>     XSETFRAME (emacs_event->frame_or_window, emacsframe);
>     EV_TRAILER2 (e);
>
> and work from there.
>

​Still doesn't seem to work if that code is used at the end of mouseDown
(called by mouseUp).
Could you test any of your ideas?  It would probably speed the process up
if you have a bit of time.

Bob

[-- Attachment #2: Type: text/html, Size: 1548 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 3484 bytes --]

On Wed, Oct 11, 2017 at 1:16 PM, Robert Weiner <rsw@gnu.org> wrote:

>
> ​Martin wrote:​
>
>> Take the position of the event-end (if it's a frame) and translate it
>> into absolute screen coordinates (the Elisp manual should give you
>> enough clues to do that).  Or, try ‘mouse-absolute-pixel-position’ - it
>> should give you the screen position of the mouse at that time so you can
>> ignore the event completely.
>>
>> Then walk all your windows and compare that position with whatever
>> ‘window-absolute-pixel-edges’ returns for that window.  If you have two
>> or more positives, run ‘frame-list-z-order’ and compare the result
>> against those windows' frames.  No hands, IMHO.
>> ​​
>>
> ​​

​  Eli wrote:
    ​​
Why cannot you compute the frame at button release using the a
​​
lgorithm
         proposed by Martin, given the mouse position at button release?​


>
>> ​​
>>
> I w
> ​​
> rote:
>   ​
> ​​
> frame-list-z-order is Emacs 26 only; I need something that works with
> older versions.​
> ​​
> ​​
> I'll see if I can make this work under Emacs 26 and then we can
> contemplate a solution that would apply to earlier versions.
> ​​
> Thanks for the reminder.  It does still seem to me that there should be a
> function that takes a mouse position and returns
> ​​
> the top-most Emacs window that the position is in or nil.  I'll work on it.
>
​​
​​​And now there is such a function.  It was easier than I expected thanks
to Martin's pointers.  Now how can we make this work (replacing
frame-list-z-order) for Emacs versions prior to 26?  -- Bob

(defun window-at-absolute-pixel-position (&optional position)
  "Return the top-most Emacs window at optional POSITION ((X . Y) in
pixels) or mouse position.
If POSITION is not in a window, return nil.  Considers all windows on the
the same terminal
display as the selected frame."
  (interactive)
  (setq position (or position (mouse-absolute-pixel-position)))
  (let* ((top-to-bottom-frames (frame-list-z-order))
(pos-x (car position))
(pos-y (cdr position))
edges left top right bottom
frame
in-frame
window)
    ;; First find top-most frame containing position.
    (while (and (not in-frame) top-to-bottom-frames)
      (setq frame (car top-to-bottom-frames)
    top-to-bottom-frames (cdr top-to-bottom-frames))
      ;; Check that in-frame is valid with frame-live-p since under macOS
      ;; when position is outside a frame, in-frame could be invalid and
      ;; frame-visible-p would trigger an error in that case.
      (when (and (frame-live-p frame) (frame-visible-p frame))
(setq edges (frame-edges frame)
      left   (nth 0 edges)
      top    (nth 1 edges)
      right  (nth 2 edges)
      bottom (nth 3 edges))
(when (and (>= pos-x left) (<= pos-x right)
   (>= pos-y top)  (<= pos-y bottom))
  (setq in-frame frame))))
    ;; If in-frame is found, find which of its windows contains
    ;; position and return that.  The window-at call below requires
    ;; character coordinates relative to in-frame, so compute them.
    (setq pos-x (/ (- pos-x left) (frame-char-width in-frame))
  pos-y (/ (- pos-y top) (frame-char-height in-frame))
  window (window-at pos-x pos-y in-frame))
    (if (called-interactively-p 'interactive)
  (message "%s at absolute pixel position %s"
   (or window "No Emacs window") position))
    window))

[-- Attachment #2: Type: text/html, Size: 9515 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 4722 bytes --]

I now have drags working across frames (after manipulating the drag button
release event data to include the proper window and coordinates, though
only in Lisp right now).  As shown in the last message, I also have a
function that finds the proper Emacs window given some display
coordinates.  The only remaining problem seems to be that none of this
accounts for external application windows that may be obscuring an Emacs
frame.

So if I have 2 frames, f1 and f2, and a Chrome web browser window that is
atop f2, then if I drag from f1 into Chrome above f2, my drag release code
reports that the release window is in f2 rather than nil, as it should be.
I am on macOS which uses click to focus, so Emacs still gets the release
event since Chrome has not been selected with a click.

Is there any way to deal with external window z-order layering such that
one can tell within Emacs whether the topmost OS-level window at an
absolute mouse position is an Emacs frame or not?

Thanks,

Bob


On Wed, Oct 11, 2017 at 2:49 PM, Robert Weiner <rsw@gnu.org> wrote:

> On Wed, Oct 11, 2017 at 1:16 PM, Robert Weiner <rsw@gnu.org> wrote:
>
>>
>> ​Martin wrote:​
>>
>>> Take the position of the event-end (if it's a frame) and translate it
>>> into absolute screen coordinates (the Elisp manual should give you
>>> enough clues to do that).  Or, try ‘mouse-absolute-pixel-position’ - it
>>> should give you the screen position of the mouse at that time so you can
>>> ignore the event completely.
>>>
>>> Then walk all your windows and compare that position with whatever
>>> ‘window-absolute-pixel-edges’ returns for that window.  If you have two
>>> or more positives, run ‘frame-list-z-order’ and compare the result
>>> against those windows' frames.  No hands, IMHO.
>>> ​​
>>>
>> ​​
>
> ​  Eli wrote:
>     ​​
> Why cannot you compute the frame at button release using the a
> ​​
> lgorithm
>          proposed by Martin, given the mouse position at button release?​
>
>
>>
>>> ​​
>>>
>> I w
>> ​​
>> rote:
>>   ​
>> ​​
>> frame-list-z-order is Emacs 26 only; I need something that works with
>> older versions.​
>> ​​
>> ​​
>> I'll see if I can make this work under Emacs 26 and then we can
>> contemplate a solution that would apply to earlier versions.
>> ​​
>> Thanks for the reminder.  It does still seem to me that there should be a
>> function that takes a mouse position and returns
>> ​​
>> the top-most Emacs window that the position is in or nil.  I'll work on
>> it.
>>
> ​​
> ​​​And now there is such a function.  It was easier than I expected thanks
> to Martin's pointers.  Now how can we make this work (replacing
> frame-list-z-order) for Emacs versions prior to 26?  -- Bob
>
> (defun window-at-absolute-pixel-position (&optional position)
>   "Return the top-most Emacs window at optional POSITION ((X . Y) in
> pixels) or mouse position.
> If POSITION is not in a window, return nil.  Considers all windows on the
> the same terminal
> display as the selected frame."
>   (interactive)
>   (setq position (or position (mouse-absolute-pixel-position)))
>   (let* ((top-to-bottom-frames (frame-list-z-order))
> (pos-x (car position))
> (pos-y (cdr position))
> edges left top right bottom
> frame
> in-frame
> window)
>     ;; First find top-most frame containing position.
>     (while (and (not in-frame) top-to-bottom-frames)
>       (setq frame (car top-to-bottom-frames)
>     top-to-bottom-frames (cdr top-to-bottom-frames))
>       ;; Check that in-frame is valid with frame-live-p since under macOS
>       ;; when position is outside a frame, in-frame could be invalid and
>       ;; frame-visible-p would trigger an error in that case.
>       (when (and (frame-live-p frame) (frame-visible-p frame))
> (setq edges (frame-edges frame)
>       left   (nth 0 edges)
>       top    (nth 1 edges)
>       right  (nth 2 edges)
>       bottom (nth 3 edges))
> (when (and (>= pos-x left) (<= pos-x right)
>    (>= pos-y top)  (<= pos-y bottom))
>   (setq in-frame frame))))
>     ;; If in-frame is found, find which of its windows contains
>     ;; position and return that.  The window-at call below requires
>     ;; character coordinates relative to in-frame, so compute them.
>     (setq pos-x (/ (- pos-x left) (frame-char-width in-frame))
>   pos-y (/ (- pos-y top) (frame-char-height in-frame))
>   window (window-at pos-x pos-y in-frame))
>     (if (called-interactively-p 'interactive)
>   (message "%s at absolute pixel position %s"
>    (or window "No Emacs window") position))
>     window))
>

[-- Attachment #2: Type: text/html, Size: 11880 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

On Wed, Oct 11, 2017 at 9:35 PM, Robert Weiner <rsw@gnu.org> wrote:

>
> Is there any way to deal with external window z-order layering such that
> one can tell within Emacs whether the topmost OS-level window at an
> absolute mouse position is an Emacs frame or not?
>

​One idea is to expand frame-list-z-order with a 2nd optional argument of
all-display-windows-flag which when non-nil would include all of the
OS-level windows in the returned list.  Maybe a new object type or
frame-variant is needed for this.  Then just add another function that
returns the edge coordinates for such windows and we could account for them
in any z-ordering computations.  What do you think?

Bob
​

[-- Attachment #2: Type: text/html, Size: 1606 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[martin rudalics]

 > So if I have 2 frames, f1 and f2, and a Chrome web browser window that is
 > atop f2, then if I drag from f1 into Chrome above f2, my drag release code
 > reports that the release window is in f2 rather than nil, as it should be.
 > I am on macOS which uses click to focus, so Emacs still gets the release
 > event since Chrome has not been selected with a click.

I would call this a feature: f2 is probably the one meaningful target of
your operation at that screen position.

 > Is there any way to deal with external window z-order layering such that
 > one can tell within Emacs whether the topmost OS-level window at an
 > absolute mouse position is an Emacs frame or not?

Not really.  Compositing window managers on X no more allow to track the
visibility of windows reliably.  So while we can discern the visibility
of our own (window manager) windows based on what we store in their
asscociated frames' 'visible' slots, we can't do that for windows of
other applications.  And processing whatever else XGetWindowAttributes
returns for another application's window might not be trivial either.

It should be possible to do what you want on Windows (where the debugger
also notifies you when an Emacs frame is obscured) though.

martin

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 3164 bytes --]

On Thu, Oct 12, 2017 at 4:05 AM, martin rudalics <rudalics@gmx.at> wrote:

> > So if I have 2 frames, f1 and f2, and a Chrome web browser window that is
> > atop f2, then if I drag from f1 into Chrome above f2, my drag release
> code
> > reports that the release window is in f2 rather than nil, as it should
> be.
> > I am on macOS which uses click to focus, so Emacs still gets the release
> > event since Chrome has not been selected with a click.
>
> I would call this a feature: f2 is probably the one meaningful target of
> your operation at that screen position.


​I think it is a feature that Emacs receives an event for this but a defect
that it can't distinguish when f2 is atop an external window or not and
thus whether the event was actually directed at f2 or not.

​​
>
> ​​
>
> ​​
> > Is there any way to deal with external window z-order layering such that
> ​​
> > one can tell within Emacs whether the topmost OS-level window at an
> ​​
> > absolute mouse position is an Emacs frame or not?
> ​​
>
> ​​
> Not really.  Compositing window managers on X no more allow to track the
> ​​
> visibility of windows reliably.  So while we can discern the visibility
> ​​
> of our own (window manager) windows based on what we store in their
> ​​
> asscociated frames' 'visible' slots, we can't do that for windows of
> ​​
> other applications.  And processing whatever else XGetWindowAttributes
> ​​
> returns for another application's window might not be trivial either.
>

​Just FYI, I am using the macOS window manager, not X, though as you note,
it is an issue there too.
The application-level window managers must have a z-ordering for all
windows in order to be able to select and raise windows when they are
behind others.  So you are saying that they don't publish this information
in any useful way that Emacs can obtain, right?

Part of the issue is that the macOS window manager uses click-to-focus, so
the release event of the drag does not switch focus to the application
whose window the release falls upon.  However, in drag-n-drop operations,
the window manager automatically switches focus to any compatible
application that the mouse moves over (after a delay) so that the right
application receives the drop (based on Z-order).

Mouse wheel events are also delivered to the topmost Z-order window without
either raising the window or switching focus.

So the window manager always knows where it should deliver at least two
kinds of events and maybe one of those types of events could be used to
help Emacs know whether a release event was over one of its frames or over
the window of an another application.

​
>
> ​​
> It should be poss
> ​​
> ​​
> ible to do what you want on Windows (where the debugger
> ​​
> also notifies you
> ​​
> when an Emacs frame is obscured) though.

​​
​​Well, one platform would be a good start.​  What would the pseudo-code
look like to check whether or not an Emacs frame was uppermost at the point
of mouse release?

Thanks,

Bob

[-- Attachment #2: Type: text/html, Size: 6853 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[martin rudalics]

 > ​I think it is a feature that Emacs receives an event for this but a defect
 > that it can't distinguish when f2 is atop an external window or not and
 > thus whether the event was actually directed at f2 or not.

‘mouse-drag-region’ is an Emacs internal function, so it's no defect.
If it were not internal, Emacs would have to be either able to poll the
other window's application as to whether it supports dropping an Emacs
internal string or convert that string to some appropriate coding that
other applications understand.  Neither of these has been done yet and
it will be non-trivial to do that for our various platforms.

 > ​Just FYI, I am using the macOS window manager, not X, though as you note,
 > it is an issue there too.
 > The application-level window managers must have a z-ordering for all
 > windows in order to be able to select and raise windows when they are
 > behind others.  So you are saying that they don't publish this information
 > in any useful way that Emacs can obtain, right?

All I can say is that when you nowadays try to obtain information on
whether a window is really visible under X, chances are that you don't
get it.  Querying the z-order will only tell you something like "window
Y cannot obscure window X because it's lower in the z-order".

 > Part of the issue is that the macOS window manager uses click-to-focus, so
 > the release event of the drag does not switch focus to the application
 > whose window the release falls upon.

As Stefan already mentioned earlier: With a drag operation usually no
focus shifting occurs anyway.

 > However, in drag-n-drop operations,
 > the window manager automatically switches focus to any compatible
 > application that the mouse moves over (after a delay) so that the right
 > application receives the drop (based on Z-order).

It's completely up to the window manager which polls the application(s)
whether they are ready to receive the object to drop.  Emacs is not
involved in that process.  It would be involved only to tell whether it
would accept such a string when it's the target of a drop.

 > Mouse wheel events are also delivered to the topmost Z-order window without
 > either raising the window or switching focus.

Mouse wheel events are completely different and highly window system
dependent.  Sometimes they get caught before Emacs sees them at all and
get transformed to scroll bar thumb drag events to the owner of the
scroll bar nearest to the mouse cursor at the time the wheel gets
scrolled.

 > So the window manager always knows where it should deliver

... it never "knows".  Some make better guesses and some make worse ...

 > What would the pseudo-code
 > look like to check whether or not an Emacs frame was uppermost at the point
 > of mouse release?

(1) ‘frame-list-z-order’ would have to be able to return all windows on
your system and (2) a function would be needed to get the attributes of
those windows.

martin

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 6257 bytes --]

Martin:

Thanks for commenting on this and sharing some of your extensive knowledge
on window event handling and Emacs.

On Sat, Oct 14, 2017 at 4:35 AM, martin rudalics <rudalics@gmx.at> wrote:

> > ​I think it is a feature that Emacs receives an event for this but a
> defect
> > that it can't distinguish when f2 is atop an external window or not and
> > thus whether the event was actually directed at f2 or not.
>
> ‘mouse-drag-region’ is an Emacs internal function, so it's no defect.
> If it were not internal, Emacs would have to be either able to poll the
> other window's application as to whether it supports dropping an Emacs
> internal string or convert that string to some appropriate coding that
> other applications understand.  Neither of these has been done yet and
> it will be non-trivial to do that for our various platforms.


​Ok, that indicates that drag-and-drop from Emacs to external applications
is unlikely but it still leaves the issue of recognizing whether a drag
release event maps to an Emacs frame or not (when the frame is covered by
an external app's window).  I already have code that recognizes this in
Lisp; we should make it a primitive so the drag release code in Emacs could
report more useful and accurate information in drag release events.

I guess you are saying that Emacs drag events must start and end within
Emacs frames.  I think about it a bit differently.  Since the mouse can
move in and out of Emacs frames and release events can occur (in logical
Z-ordered OS window space) outside of Emacs, yet still register with Emacs
(when the release occurs within the geometry of a frame but the frame is
covered by another app's window), I think Emacs event handling should
return different information when the release frame is not the topmost
OS-level window at the point of release.  Then handler code could dispatch
as necessary.

I already have Lisp code doing useful things with such information
(presently, I have to adjust the drag release event information).  So I
know it would be helpful to have this as default Emacs event reporting
behavior.

​​
>
> ​​
> > ​Just FYI, I am using the macOS window manager, not X, though as you
> note,
> ​​
> > it is an issue there too.
> ​​
> > The application-level window managers must have a z-ordering for all
> ​​
> > windows in order to be able to select and raise windows when they are
> ​​
> > behind others.  So you are saying that they don't publish this
> information
> ​​
> > in any useful way that Emacs can obtain, right?
> ​​
>
> ​​
> All I can say is that when you nowadays try to obtain information on
> ​​
> whether a window is really visible under X, chances are that you don't
> ​​
> g
> ​​
> e
> ​​
> t
> ​​
> ​​
> i
> ​​
> t
> ​​
> .


​Each window has a 'visible' attribute.  Are you saying this is not
accurate these days?​
​​​

> ​
>   Querying the z-order will only tell you something like "window
> ​​
> Y cannot obscure window X because it's lower in the z-order".


​We just want to know when given a screen position whether an Emacs frame
is topmost at that position or not.​
​​​

> ​​
>
> ​​
> > Part of the issue is that the macOS window manager uses click-to-focus,
> so
> ​​
> > the release event of the drag does not switch focus to the application
> ​​
> > whose window the release falls upon.
> ​​
>
> ​​
> As Stefan already mentioned earlier: With a drag operation usually no
> ​​
> focus shifting occurs anyway.


For the interactive things I am doing, I find that selecting the window of
mouse release is always best but I agree it is not necessary in all
instances.

​​
>
> ​
> > However, in drag-n-drop operations,
> ​​
> > the window manager automatically switches focus to any compatible
> ​​
> > application that the mouse moves over (after a delay) so that the right
> ​​
> > application receives the drop (based on Z-order).
> ​​
>
> ​​
> It's completely up to the window manager which polls the application(s)
> ​​
> whether they are ready to receive the object to drop.  Emacs is not
> ​​
> involved in that process.  It would be involved only to tell whether it
> ​​
> would accept such a string when it's the target of a drop.


​I understand that.  I was just noting that there is an example of a drag
release event handler that selects the window of release as a standard part
of its operation.

​​
>
> ​​
>
> ​​
> > Mouse wheel events are also delivered to the topmost Z-order window
> without
> ​​
> > either raising the window or switching focus.
> ​​
>
> ​​
> Mouse wheel events are completely different and highly window system
> ​​
> dependent.  Sometimes they get caught before Emacs sees them at all and
> ​​
> get transformed to scroll bar thumb drag events to the owner of the
> ​​
> scroll bar nearest to the mouse cursor at the time the wheel gets
> ​​
> scrolled.


​Again, I was just providing context of what might be possible based on
other event handling that occurs already in Emacs under macOS.​

​​
>
> ​
> ​​
> > So the window manager always knows where it should deliver
> ​​
>
> ​​
> ... it never "knows".  Some make better guesses and some make worse ...


​On macOS the scroll wheel events seem to go to the right window 100% of
the time from what I have seen.​

​​
>
> ​
> ​​
> > What would the pseudo-code
> ​​
> > look like to check whether or not an Emacs frame was uppermost at the
> point
> ​​
> > of mouse release?
> ​​
>
> ​​
> (1) ‘frame-list-z-order’ would have to be able to return all windows on
> ​​
> your system


​Is it likely we could build a multi-platform primitive ​that would supply
that information given what you have said?
​​​

> ​​
> and (2) a function would be needed to get the attributes of
> ​​
> those windows.


​2 seems straightforward.

Bob
​​

[-- Attachment #2: Type: text/html, Size: 15485 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

On Sat, Oct 14, 2017 at 1:16 PM, Robert Weiner <rsw@gnu.org> wrote:

> it still leaves the issue of recognizing whether a drag release event maps
> to an Emacs frame or not (when the frame is covered by an external app's
> window).  I already have code that recognizes this in Lisp; we should make
> it a primitive so the drag release code in Emacs could report more useful
> and accurate information in drag release events.
>

​I misspoke.  I have code that detects when the release falls outside of
the bounds of any Emacs frame.  However, when the release event is over an
Emacs frame that is covered by another application's window, we don't yet
have any information to tell us that, so I cannot detect it yet.  That is
the problem we are discussing how to solve in a general way.

Bob
​

[-- Attachment #2: Type: text/html, Size: 1671 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

On Sat, Oct 14, 2017 at 2:47 PM, Robert Weiner <rsw@gnu.org> wrote:

> On Sat, Oct 14, 2017 at 1:16 PM, Robert Weiner <rsw@gnu.org> wrote:
>
>> it still leaves the issue of recognizing whether a drag release event
>> maps to an Emacs frame or not (when the frame is covered by an external
>> app's window).
>>
>
​I have written a Python script that can be used to get this answer.  (It
uses the Python-to-Objective-C bridge library that exposes the relevant Mac
APIs to Python)​.  The script  takes two arguments, X and Y screen pixel
coordinates, gets a list of all visible application windows in Z-order and
then prints the application name of the first window that intersects the
(X,Y) position, if any.  If that window is an Emacs frame, we have a match
and otherwise, we don't.

This is a short script that really needs to be recoded into an Objective-C
function that can be exposed to Emacs Lisp.  If anyone who is familiar with
macOS Objective-C code would want to work with me on this, email me and
I'll provide the Python code.  It is only about 28 lines.  -- Bob

[-- Attachment #2: Type: text/html, Size: 2616 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[martin rudalics]

 > ​Ok, that indicates that drag-and-drop from Emacs to external applications
 > is unlikely but it still leaves the issue of recognizing whether a drag
 > release event maps to an Emacs frame or not (when the frame is covered by
 > an external app's window).  I already have code that recognizes this in
 > Lisp; we should make it a primitive so the drag release code in Emacs could
 > report more useful and accurate information in drag release events.

Even if the Emacs frame is covered by another application's frame,
nothing prevents us from having that covered Emacs frame accept the
drop.  We could even give frames a "no-accept-drops" parameter and this
way have a drop on such frames pass the drop through to yet another
frame below that does accept drops.

 > I guess you are saying that Emacs drag events must start and end within
 > Emacs frames.  I think about it a bit differently.  Since the mouse can
 > move in and out of Emacs frames and release events can occur (in logical
 > Z-ordered OS window space) outside of Emacs, yet still register with Emacs
 > (when the release occurs within the geometry of a frame but the frame is
 > covered by another app's window), I think Emacs event handling should
 > return different information when the release frame is not the topmost
 > OS-level window at the point of release.  Then handler code could dispatch
 > as necessary.

But to be useful, that "handler code" must be written and such code must
follow a standard interface for the OS used.  Consider the trivial task
that one Emacs instance wants to drop some text to a second Emacs
instance.  How would we trigger the drop event on that second instance?

 > ​Each window has a 'visible' attribute.  Are you saying this is not
 > accurate these days?​

Yes.  The GTK manual says that

   Modern composited windowing systems with pervasive transparency make
   it impossible to track the visibility of a window reliably,

 >> (1) ‘frame-list-z-order’ would have to be able to return all windows on
 >> ​​
 >> your system
 >
 >
 > ​Is it likely we could build a multi-platform primitive ​that would supply
 > that information given what you have said?

At least for top-level windows.  This will work as long a child windows
are fully contained by their parents which IIUC is not necessarily true
for macOS systems.

 >> and (2) a function would be needed to get the attributes of
 >> ​​
 >> those windows.
 >
 >
 > ​2 seems straightforward.

How accurate these attributes will be depends on the windowing system
used.  Look at how hard frame_geometry occasionally works to just get
the real screen estate of an Emacs frame.

martin

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 4490 bytes --]

On Sun, Oct 15, 2017 at 5:40 AM, martin rudalics <rudalics@gmx.at> wrote:

>
> Even if the Emacs frame is covered by another application's frame,
> nothing prevents us from having that covered Emacs frame accept the
> drop.  We could even give frames a "no-accept-drops" parameter and this
> way have a drop on such frames pass the drop through to yet another
> frame below that does accept drops.


​Yes.  My point is that there should be some extension to Emacs'
reporting of window system events that allows a user of such
information to know whether any other application occluded the
Emacs frame at the time and point of release.  Then in cases
where this information can be gleaned from the external window
manager, it can be used in programs.  The user program is still
free to allow a drop to go through in such cases but only if
desired.

​​
>
> ​​
> > I guess you are saying that Emacs drag events must start and end within
> ​​
> > Emacs frames.  I think about it a bit differently.  Since the mouse can
> ​​
> > move in and out of Emacs frames and release events can occur (in logical
> ​​
> > Z-ordered OS window space) outside of Emacs, yet still register with
> Emacs
> ​​
> > (when the release occurs within the geometry of a frame but the frame is
> ​​
> > covered by another app's window), I think Emacs event handling should
> ​​
> > return different information when the release frame is not the topmost
> ​​
> > OS-level window at the point of release.  Then handler code could
> dispatch
> ​​
> > as necessary.
> ​​
>
> ​​
> But to be useful, that "handler code" must be written and such code must
> ​​
> f
> ​​
> o
> ​​
> l
> ​​
> l
> ​​
> o
> ​​
> w
> ​​
> ​​
> a
> ​​
> ​​
> s
> ​​
> t
> ​​
> a
> ​​
> n
> ​​
> d
> ​​
> a
> ​​
> rd interface for the OS used.


​It is not only drag-and-drop that we are interested in.  We
often want to simply call different functions based on whether
the drag release was inside or outside of Emacs.  For example,
Hyperbole now uses a drag release outside of Emacs to clone the
window depressed upon into a new frame.​

​​
>   Consider the trivial task
> ​​
>
> ​​
> that one Emacs instance wants to drop some text to a second Emacs
> ​​
> instance.  How would we trigger the drop event on that second instance?


​Yes, you would need to follow a common drag-and-drop protocol.
I don't understand why that is an issue if that is what you want
to do.

​​
>
> ​
> > ​Each window has a 'visible' attribute.  Are you saying this is not
> ​​
> > accurate these days?​
> ​​
>
> ​​
> Yes.  The GTK manual says that
> ​​
>
> ​​
>   Modern composited windowing systems with pervasive transparency make
> ​​
>   it impossible to track the visibility of a window reliably,


For programmatic purposes when Emacs receives a mouse button
drag release event, we only care about whether the topmost
window-system window at the point of release is an Emacs frame
or not.  If at that point, it is occluded by another window,
we don't care how transparent that window is and whether the
Emacs frame can be "seen" but only whether it is logically
the window clicked upon.  Again, even if it is not, we can
process the event as if it were *if we so choose* but having
the choice is the key issue here.

​​
>
> ​​
>
> ​​
> >> (1) ‘frame-list-z-order’ would have to be able to return all windows on
> ​
> ​
> your system
> ​
> ​​
> >
> ​​
> > ​Is it likely we could build a multi-platform primitive ​that would
> supply
> ​​
> > that information given what you have said?
> ​​
>
> ​​
> At least for top-level windows.  This will work as long a child windows
> ​​
> are fully contained by their parents which IIUC is not necessarily true
> ​​
> for macOS systems.


​Could you give a concrete example of where this might be a problem
so I could test code against it?
​

> ​​
>
> ​
> ​​
> >
> ​​
> > and (2) a function would be needed to get the attributes of
> ​
> ​​
>  those windows.
> ​​
> ​​
> ​​
> ​​
> ​​
> ​​
> ​​
> ​​
>

​I have figured that part out from the macOS APIs.
​
Bob
​

[-- Attachment #2: Type: text/html, Size: 14055 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[martin rudalics]

 > ​Yes, you would need to follow a common drag-and-drop protocol.
 > I don't understand why that is an issue if that is what you want
 > to do.

Wasn't that something _you_ wanted to do?  If not then we can obviously
ignore it.

 > For programmatic purposes when Emacs receives a mouse button
 > drag release event, we only care about whether the topmost
 > window-system window at the point of release is an Emacs frame
 > or not.  If at that point, it is occluded by another window,
 > we don't care how transparent that window is and whether the
 > Emacs frame can be "seen" but only whether it is logically
 > the window clicked upon.  Again, even if it is not, we can
 > process the event as if it were *if we so choose* but having
 > the choice is the key issue here.

So I warned here about possible problems with "visibility" once and will
drop this issue.

 >> At least for top-level windows.  This will work as long a child windows
 >> ​​
 >> are fully contained by their parents which IIUC is not necessarily true
 >> ​​
 >> for macOS systems.
 >
 >
 > ​Could you give a concrete example of where this might be a problem
 > so I could test code against it?

Hardly.  Child windows are a separate problem because, for example, on X
you currently cannot drop files on them - the drop goes to the parent
window instead.

 >>> and (2) a function would be needed to get the attributes of
 >> ​
 >> ​​
 >>   those windows.
 >> ​​
 >> ​​
 >> ​​
 >> ​​
 >> ​​
 >> ​​
 >> ​​
 >> ​​
 >>
 >
 > ​I have figured that part out from the macOS APIs.

Window attributes are a problem on X.  You will learn about that as soon
as you try to adapt your code for it.

martin

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]

On Tue, Oct 17, 2017 at 4:57 AM, martin rudalics <rudalics@gmx.at> wrote:

> > ​Yes, you would need to follow a common drag-and-drop protocol.
> > I don't understand why that is an issue if that is what you want
> > to do.
>
> Wasn't that something _you_ wanted to do?  If not then we can obviously
> ignore it.


​Yes, I would like Emacs drag-and-drop to work across Emacs frames and
potentially even across other applications using whatever protocol is
common to the platform in use.


>
> >> At least for top-level windows.  This will work as long a child windows
> >> ​are fully contained by their parents which IIUC is not necessarily true
> >> ​
> ​f​
> or macOS systems.
> >
> > ​Could you give a concrete example of where this might be a problem
> > so I could test code against it?
>
> Hardly.  Child windows are a separate problem because, for example, on X
> you currently cannot drop files on them - the drop goes to the parent
> window instead.


​We would certainly live within the constraints of the drag-and-drop
protocol.
​

>
>
> >>> and (2) a function would be needed to get the attributes of
> >>   those windows.
> >
> > ​I have figured that part out from the macOS APIs.
>
> Window attributes are a problem on X.  You will learn about that as soon
> as you try to adapt your code for it.


​Ok.  It would be more helpful if you explained which problems you feel are
relevant to the discussion at hand.
​
Bob

[-- Attachment #2: Type: text/html, Size: 3130 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[martin rudalics]

 > ​Ok.  It would be more helpful if you explained which problems you feel are
 > relevant to the discussion at hand.

For example that of getting the screen dimensions of a window.  Have a
look at x_real_pos_and_offsets to get an idea of the tribulations needed
to do that for an Emacs frame.  These are by far the most complicated
operations we do in the X specific code and I have reports that we still
do not get the right results everywhere.

martin

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

On Fri, Oct 20, 2017 at 3:55 AM, martin rudalics <rudalics@gmx.at> wrote:

> > ​Ok.  It would be more helpful if you explained which problems you feel
> are
> > relevant to the discussion at hand.
>
> For example that of getting the screen dimensions of a window.  Have a
> look at x_real_pos_and_offsets to get an idea of the tribulations needed
> to do that for an Emacs frame.  These are by far the most complicated
> operations we do in the X specific code and I have reports that we still
> do not get the right results everywhere.


​Yes, I see.  I am having similar issues when trying to replicate the size
of a frame under the macOS window system.  I can't seem to get the new
frame to match the old frame by using (frame-edges nil 'outer-edges) or
(frame-edges nil 'native-edges).  In earlier versions of Emacs, I don't
remember this being a problem but I can't recall when that was.  What is
the best way available to replicate the size of one frame to another given
the limitations that exist now?

Bob

[-- Attachment #2: Type: text/html, Size: 1898 bytes --]

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[martin rudalics]

 > ​Yes, I see.  I am having similar issues when trying to replicate the size
 > of a frame under the macOS window system.  I can't seem to get the new
 > frame to match the old frame by using (frame-edges nil 'outer-edges) or
 > (frame-edges nil 'native-edges).  In earlier versions of Emacs, I don't
 > remember this being a problem but I can't recall when that was.  What is
 > the best way available to replicate the size of one frame to another given
 > the limitations that exist now?

There should be no "limitations".  As a rule,

(setq frame-resize-pixelwise t)
(make-frame (frame-parameters))

should give you an exact replica of the selected frame.  If you only
want to clone the size of the selected frame use

(setq frame-resize-pixelwise t)
(make-frame `((width . ,(frame-parameter nil 'width))
	      (height . ,(frame-parameter nil 'height))))

martin

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

[Richard Stallman]

I am trying to imagine what a mouse drag event would look like.
Since mice don't wear clothing, or makeup, what would distinguish
it from any other mouse event?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.