Subject: Re: bug#26816: mouse movement support for OS X

From: Alan Third <[email-masked]>
Date: Tue, 9 May 2017 23:44:35 +0100

On Tue, May 09, 2017 at 09:09:29PM +0200, Charles A. Roelli wrote:
> With the frame in the taller monitor as mentioned, after calling
> (set-mouse-position (selected-frame) 0 0), (mouse-position) returns (#<frame
> *scratch* 0x1058883a8> 0 . 55), which happens to be about 800 pixels from
> the place where it should end up (i.e. it sounds like the calculation is off
> the mark by the height of the primary monitor).
> 
> > It might be that NS_PARENT_WINDOW_TOP_POS
> > isn’t taking that extra height into account.
> > 
> > #define NS_PARENT_WINDOW_TOP_POS(f)                                     \
> >    (FRAME_PARENT_FRAME (f) != NULL                                       \
> >     ? ([[FRAME_NS_VIEW (f) window] parentWindow].frame.origin.y          \
> >        + [[FRAME_NS_VIEW (f) window] parentWindow].frame.size.height     \
> >        - FRAME_NS_TITLEBAR_HEIGHT (FRAME_PARENT_FRAME (f)))              \
> >     : [[[FRAME_NS_VIEW (f) window] screen] frame].size.height)
> > 
> > That last line just takes the screen’s height, and I guess that’s
> > wrong. It should probably be the top left co‐ord (origin.y +
> > size.height)?
> > 
> 
> 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)?

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.

-- 
Alan Third