GNU bug report logs - #26816
mouse movement support for OS X

Previous Next

Package: emacs;

Reported by: "Charles A. Roelli" <charles <at> aurox.ch>

Date: Sun, 7 May 2017 15:13:01 UTC

Severity: normal

Tags: fixed

Fixed in version 26.1

Done: Alan Third <alan <at> idiocy.org>

Bug is archived. No further changes may be made.

Full log


Message #26 received at 26816 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: 26816 <at> debbugs.gnu.org
Subject: Re: bug#26816: mouse movement support for OS X
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




This bug report was last modified 8 years and 54 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.