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

Previous Next

Full log

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

From: "Charles A. Roelli" <charles <at> aurox.ch>
To: Alan Third <alan <at> idiocy.org>
Cc: 26816 <at> debbugs.gnu.org
Subject: Re: bug#26816: mouse movement support for OS X
Date: Thu, 11 May 2017 20:06:13 +0200

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

Previous Next

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