Ticket UUID: | b389dfcd8f241fca5f9b06a6025a992e5b249884 | |||
Title: | Mouse click positions reported wrongly on dual-screen Mac | |||
Type: | Bug | Version: | core-8-6-branch | |
Submitter: | jal_frezie | Created on: | 2019-02-11 13:29:13 | |
Subsystem: | 01. Bindings | Assigned To: | nobody | |
Priority: | 5 Medium | Severity: | Severe | |
Status: | Closed | Last Modified: | 2019-02-13 10:15:42 | |
Resolution: | Fixed | Closed By: | jal_frezie | |
Closed on: | 2019-02-13 10:15:42 | |||
Description: |
If you have a dual-screen setup on a Mac, the mouse y position supplied to click event commands is wrong for windows on the secondary screen. To demonstrate, start wish and type bind . <Button-1> {puts %x,%y} Now clicking in the top-level window while it is on the secondary display will print coordinates like 80,-306 It seems the error is the same whatever the screen arrangement. However by altering the resolution of my secondary screen I can show that the magnitude of the error is equal to the difference in vertical resolution between the two screens. | |||
User Comments: |
jal_frezie added on 2019-02-13 10:15:42:
I can confirm that this fixes the problem -- thanks very much Marc marc_culler (claiming to be Marc Culler) added on 2019-02-13 03:44:45: This bug occurs on line 83 of tkMacOSXWindowEvent.c in the implementation of the windowBoundsChanged method. When converting the Apple screen y-coordinate to the Tk screen y-coordinate, the height of the window's screen (i.e. the secondary screen) was used in place of tkMacOSXZeroScreenHeight. This results in an error in the y coordinate which, as @jal_frezie observed, is equal to the difference of the heights of the two screens. A fix has been pushed to the bug-b389dfcd8f branch as check-in d583ba595e. Please review this fix! marc_culler (claiming to be Marc Culler) added on 2019-02-12 14:11:40: Apple's screen coordinate system has its origin at the bottom left corner of the primary display with increasing y values moving upward. Tk's screen coordinate system has the origin at the top left corner of the primary display with increasing y moving downward. So converting Apple screen coordinates to Tk screen coordinates is done by the transformation y -> ZeroScreenHeight - y. In fact, ZeroScreenHeight is a global variable in macosx/tkMacOSXXStubs.c which gets reset by the function tkMacOSXDisplayChanged when the NSApplication receives an NSApplicationDidChangeScreenParametersNotification. One possible explanation for the symptoms you are seeing would be that Tk and Apple disagree on which is the primary display, causing Tk to convert Apple screen coordinates to Tk screen coordinates using the screen height of the display that Apple thinks is the secondary display. In that case the discrepancy would be the difference of the heights of the two displays. Perhaps Apple is somehow interchanging the roles of the two displays without notifying Tk, I wonder whether changing the state of the setting "Displays have separate Spaces" (in the display preferences) would have any effect on the symptoms that you are seeing. oehhar added on 2019-02-12 06:55:25: Sorry, wrong comment. jal_frezie added on 2019-02-11 18:37:08: I am talking about the lowercase %x and %y dummy arguments, which should substitute to the mouse coordinates relative to the top left corner of the widget. The %y coordinate should only be negative if you click in the title bar of a toplevel. This bug is only in the current core-8-6-branch, not in the released Tk 8.6.9.1 oehhar added on 2019-02-11 17:50:39: Jasper, thank you for the ticket. I suppose, that is the intended functionality. If you set the 2nd screen on the left side, you get negative coordinates for clicks on it. If you define it on the right side, you get x coordinates larger than the main screen. It is like a big virtual screen with 0.0 at the bottom-left corner of the main screen. An example is the BWidget boublehelp, which takes care that the help window does not cross a screen border. See the procedur "DynamicHelp::_show_help" in file dynhelp: https://core.tcl.tk/bwidget/artifact/fe5b9d560cf3f3de?ln=701,724 I am on Windows, but I suppose, this is the same on Mac-OS |