Tk Source Code

View Ticket
Login
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