From: Alan Third <alan@idiocy.org>
To: "Charles A. Roelli" <charles@aurox.ch>
Cc: 26905@debbugs.gnu.org
Subject: bug#26905: 25.2: MacOS: tooltips show in wrong display
Date: Sat, 13 May 2017 16:28:21 +0100 [thread overview]
Message-ID: <20170513152821.GA13308@breton.holly.idiocy.org> (raw)
In-Reply-To: <ae367062-503e-93ae-d772-de7d812eda39@aurox.ch>
On Sat, May 13, 2017 at 11:02:04AM +0200, Charles A. Roelli wrote:
> I notice now, though, that the tooltip can end up partially offscreen, both
> with and without the above change (e.g. when you create a tooltip with the
> mouse pointer at the right edge of the primary monitor). IIRC on GNU/Linux
> the tooltip is adjusted to fit on screen. Maybe this adjustment works on
> newer versions of OS X?
I was thinking about this earlier and I suspect that if we want to
avoid tooltips crossing monitors we’ll have to step through each
screen in [NSScreen screens], check if `pt` is within it’s bounds, and
when we find the right screen, use it’s origin and frame to calculate
the min/max x/y.
constrain_frame_rect in nsterm.m does something similar already.
There’s a method in CGRect called CGRectContainsPoint, which should
help us here, as NSRect is really just a CGRect. Unfortunately it
doesn’t appear to be available in GNUstep, so it may be necessary to
implement the check ourselves.
If we don’t care about spanning monitors, I think we still need to
step through each screen and calculate the overall min/max values.
What do you think?
--
Alan Third
next prev parent reply other threads:[~2017-05-13 15:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-13 7:43 bug#26905: 25.2: MacOS: tooltips show in wrong display Charles A. Roelli
2017-05-13 9:02 ` Charles A. Roelli
2017-05-13 9:56 ` Eli Zaretskii
2017-05-13 14:04 ` Charles A. Roelli
2017-05-13 15:28 ` Alan Third [this message]
2017-05-16 21:56 ` bug#26905: [PATCH] Show tooltip on correct screen (bug#26905) Alan Third
2017-05-19 16:30 ` Charles A. Roelli
2017-05-20 23:15 ` Alan Third
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=20170513152821.GA13308@breton.holly.idiocy.org \
--to=alan@idiocy.org \
--cc=26905@debbugs.gnu.org \
--cc=charles@aurox.ch \
/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.