|
From: | Charles A. Roelli |
Subject: | bug#26905: 25.2: MacOS: tooltips show in wrong display |
Date: | Sat, 13 May 2017 09:43:27 +0200 |
User-agent: | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
On 11/05/2017 23:43, Alan Third wrote:
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.Look at compute_tip_xy in nsfns.m. It moves tooltips into the positive screen space. I’ve not managed to get to grips with this code yet. I think what we want is for it to try to keep the tooltip on one screen, so it’s not spanning two monitors, but allow it to go into negative space. Perhaps this should be a separate bug report.
"Primary" and "secondary" monitors are as follows: (display-monitor-attributes-list) => (((name . "Color LCD") (geometry 0 0 1280 800) (workarea 0 22 1280 714) (mm-size 290 180)(frames #<frame emacs-devel 0x105044260> #<frame *Backtrace* 0x1199eca10> #<frame *vc-diff* 0x117dc82b8> #<frame nsterm.m 0x121c49ad8> #<frame *shell* 0x119adf830> #<frame *Minibuf-1* 0x119b33030>)
(source . "NS")) ((name . "DELL 2007WFP") (geometry -1050 -880 1050 1680) (workarea -1050 -880 1050 1680) (mm-size 430 270) (frames #<frame nsterm.h 0x117c83fd0>) (source . "NS")))
[Prev in Thread] | Current Thread | [Next in Thread] |