bug#26816: mouse movement support for OS X

["Charles A. Roelli" <charles@aurox.ch>]

>> I ran NS_PARENT_WINDOW_TOP_POS(f) on the frame in the taller monitor as
>> described, and it always returned 1680.  I tried adding ([[[FRAME_NS_VIEW
>> (f) window] screen] frame].origin.y) to the last line in the macro you
>> mentioned, but this must always be returning zero, because it made no
>> difference and the macro still returned 1680.
> Hmm, this is harder than I first thought.
>
> Presumably (frame-position) returns nonsensical values on your
> portrait monitor, and (set-frame-position nil 0 0) also plants the
> frame in the wrong place (ie. not the top left)?

(set-frame-position nil 0 0) places the frame in the top-left corner of 
the primary monitor for me in Emacs 25.2.  (frame-position) with the 
frame in the top-left corner of the secondary monitor reports (-1050 . 
-880).

I'm not sure: is this expected behavior?

> Can you try changing that last line of NS_PARENT_WINDOW_TOP_POS to
> return
>
>      NSScreen.screens[0].frame.size.height
>
> I *think* that should set the top left of the primary screen as (0,
> 0). If that works for this, there may be other places where we’re
> using window.screen that we’ll have to change to use the primary
> screen, but I’m not really sure.
>
> I wonder if it’ll break when ‘screens have separate spaces’ is turned
> on...? :/
>
> Almost anything seems to work here, but I’m not using multiple
> monitors.
>

I made the line say [[[NSScreen screens] objectAtIndex: 0] 
frame].size.height (equivalent to what you wrote) and the mouse can now 
be set to a position in the frame as expected.  Thanks for your help 
with this.

This now reminds me of a related problem, though: with Emacs 25.2 (or in 
Emacs 26, with the above change applied to NS_PARENT_WINDOW_TOP_POS(f)), 
tooltips originating from an area with a help-echo property (like "Lisp 
Interaction" in the mode line in emacs -Q) in a frame on the secondary 
monitor actually show up in the primary monitor instead -- as if the 
tooltip frame is constrained to having a positive x-coordinate only.  I 
haven't found where it happens, but I guess the cause is similar.