|
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.
[Prev in Thread] | Current Thread | [Next in Thread] |