bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#26816: mouse movement support for OS X


From: Charles A. Roelli
Subject: bug#26816: mouse movement support for OS X
Date: Thu, 11 May 2017 20:06:13 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]