From: "Charles A. Roelli" <charles@aurox.ch>
To: Alan Third <alan@idiocy.org>
Cc: 26816@debbugs.gnu.org
Subject: bug#26816: mouse movement support for OS X
Date: Tue, 9 May 2017 21:09:29 +0200 [thread overview]
Message-ID: <b2270f81-3460-9d02-8257-661eb1b61c9a@aurox.ch> (raw)
In-Reply-To: <20170507200034.GA661@breton.holly.idiocy.org>
On 07/05/2017 22:00, Alan Third wrote:
>> diff --git a/src/nsterm.m b/src/nsterm.m
>> index c22c5a7..e81b7ee 100644
>> --- a/src/nsterm.m
>> +++ b/src/nsterm.m
>> @@ -2322,14 +2322,14 @@ so some key presses (TAB) are swallowed by the
>> system. */
>> {
>> NSTRACE ("frame_set_mouse_pixel_position");
>> ns_raise_frame (f);
>> -#if 0
>> - /* FIXME: this does not work, and what about GNUstep? */
>> + /* FIXME: what about GNUstep? */
>> #ifdef NS_IMPL_COCOA
>> [FRAME_NS_VIEW (f) lockFocus];
> AFAICT this call to lockFocus isn’t required. It should tie subsequent
> actions to the NSView, however CGWarpMouseCursorPosition always uses
> the global screen space.
>
>> - PSsetmouse ((float)pix_x, (float)pix_y);
>> + CGPoint mouse_pos = CGPointMake(f->left_pos + pix_x,
>> + f->top_pos + pix_y);
>> + CGWarpMouseCursorPosition (mouse_pos);
>> [FRAME_NS_VIEW (f) unlockFocus];
> Same with unlockFocus.
>
>> (test with (set-mouse-position (selected-frame) 0 0))
> set-mouse-position takes coordinates in characters, so (0, 0) should,
> I think, be below the title and tool bars. You should be able to just
> add (or subtract?) FRAME_NS_TITLEBAR_HEIGHT and FRAME_TOOLBAR_HEIGHT
> to get it in the right place.
>
> Unless I’ve misunderstood it.
Right, right and right: I got rid of the [un]lockFocus calls, and added
in the adjustments for the toolbar height and titlebar height. After
this, moving the mouse
to position x, y with:
(set-mouse-position (selected-frame) x y)
results in a call to (mouse-position) returning (<frame ...> x . y) --
except for the specific case I mentioned (see below). I'm still working
on the patch, and will send a new one in the next few days.
>> Still some things to fix:
>>
>> With a portrait monitor to the left of the main monitor (the left monitor
>> being in the negative x-coord. space), running the above test code on a
>> single frame inside the left monitor leaves the mouse pointer about half a
>> frame further down than the bottom-left corner of the frame. The pointer
>> should end up in the top-left corner.
> Does this mean that the top of the portrait monitor is higher than the
> top of the main monitor?
Yes. For reference, this is what (display-monitor-attributes-list)
gives in Emacs 25.2:
(((name . "Color LCD")
(geometry 0 0 1280 800)
(workarea 0 22 1280 714)
(mm-size 290 180)
(frames #<frame emacs-devel 0x105058460> #<frame nsterm.h 0x1179a1500>)
(source . "NS"))
((name . "DELL 2007WFP")
(geometry -1050 -880 1050 1680)
(workarea -1050 -880 1050 1680)
(mm-size 430 270)
(frames #<frame *Minibuf-1* 0x1189a4198>)
(source . "NS")))
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.
next prev parent reply other threads:[~2017-05-09 19:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-07 15:11 bug#26816: mouse movement support for OS X Charles A. Roelli
2017-05-07 16:51 ` Eli Zaretskii
2017-05-08 18:34 ` Charles A. Roelli
2017-05-08 18:54 ` Eli Zaretskii
2017-05-07 18:07 ` martin rudalics
2017-05-07 20:00 ` Alan Third
2017-05-09 19:09 ` Charles A. Roelli [this message]
2017-05-09 22:44 ` Alan Third
2017-05-11 18:06 ` Charles A. Roelli
2017-05-11 21:43 ` Alan Third
2017-05-14 13:29 ` Charles A. Roelli
2017-05-14 13:59 ` Alan Third
2017-05-14 14:37 ` Eli Zaretskii
2017-05-15 18:23 ` Charles A. Roelli
2017-05-16 22:53 ` Alan Third
2017-05-17 8:36 ` Andreas Schwab
2017-05-18 19:43 ` Charles A. Roelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b2270f81-3460-9d02-8257-661eb1b61c9a@aurox.ch \
--to=charles@aurox.ch \
--cc=26816@debbugs.gnu.org \
--cc=alan@idiocy.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.