On Fri, Sep 29, 2017 at 4:34 AM, martin rudalics <rudalics@gmx.at> wrote:

> > ​The behavior is the same either way.  It is definitely a bug in Emacs
> 25.2
> > and 25.3 as I have confirmed it on both MacOS and Windows 7 using just
> > default mouse-1 ​drags between frames.
>
> Do you mean that earlier Emacsen behave differently in this regard?


​No, just that I tested only with those versions.
​

> >> The start event seems to look OK.  As for the end event, an X-coordinate
> >> of -1373 does not look reasonable.
> >
> >
> > ​Right.  Is a negative value ever valid in this context?
>
> I think so.  For example if you want to move your frame to that position
> on the screen.


​Ok.
​

> > My claim is that if you put 2 frames on screen (start with
> non-overlapping)
> > and drag mouse-1 from the text area of one to the second, that the drag
> > event generated upon the release of mouse-1 will contain frame1 rather
> than
> > frame2 (where the release happened).​
>
> IIUC Emacs never was able to do that.  Mouse dragging events so far make
> sense only for the one-frame case.


​This needs to be fixed as it is a very natural gesture to
move between frames.  For the text area, this is moving
between windows which just happen to occupy different frames.
​

>   What you want involves much more
> trickery: If you have two target frames covering the same screen
> position, which one would you choose when releasing the mouse at that
> position?  Probably the one higher in the z-order.


​Yes.  It may be easier to think of it in terms of the window
of release rather than the frame​ as one will almost always
need to know the window as well.
​​
One initial way to decrease the complexity is to make this work
only when both the depress and release commands set the selected
window.  Then the posn- functions would have a unique window to
report.

​​
>   But only Emacs 26
> ​​
> can handle that and we would have to write routines to do it.


​Ok
.

> ​​
>
> ​​
> Or
> ​​
> ​​
> ​​
> ​​
> ​​
>
> ​​
> the one that gets focus during mouse tracking because your window
> ​​
> manager has some sort of focus-follows-mouse installed?  Then you would
> ​​
> ​​
> ​​
> ​​
> ​​
> ​​
> ​​
> ​​
> ​​
> ​​
> ​​
>
> ​​
> have to query the focus when you release the mouse.  Non-trivial.


​See above.

Thanks much for the feedback.  I can say that if this is
implemented, it will lead to improved user interfaces and
faster inter-frame control in many instances.

Bob
​