This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch (diff.txt, text/plain, 2014-08-08 17:21:49 +0000, 4354 bytes)
• Removed ASL_SDL macro switches (export9012.diff, text/plain, 2014-08-09 19:48:24 +0000, 4932 bytes)

Reported in version: don't know
Reported for operating system, platform: Mac OS X (All), All

Comments on the original bug report:

On 2014-07-18 20:50:18 +0000, Tim McDaniel wrote:

On OSX, with revision 8729, the coordinate space for window position and the coordinate space for global mouse position don't match. For a non-fullscreen window, the window position is global relative to the bottom of the menubar. The global mouse position is relative to the top of the screen. This affects Cocoa_WarpMouse and potentially other things as well. Further, the coordinate system for window position is now affected by what screen it is on. For example, if I have two equal size screens oriented side by side such that the tops of the screens are equal in global space, with the menubar on one screen, and a window straddles the two screens, the window's y position makes no sense. The window's y position depends on what screen "most" of the window is on. So if I move the window horizontally just a bit, the y position of my window is now different by the size of the menubar, even though the window was not moved vertically.

On 2014-07-24 18:35:10 +0000, Tim McDaniel wrote:

I'd like to reiterate that this was a fairly fundamental change (and a breaking change for us). If SDL OSX is to really support multi-display configurations, this is especially problematic.

If the real concern is preventing windows from going under the menubar, then perhaps a solution involving something like overriding [NSWindow constrainFrameRect] would be less problematic than redefining the global window coord space for the main display.

I recommend reverting SDL_cocoawindow.m revisions 8801, 8739, 8729.

On 2014-08-08 17:21:49 +0000, Tim McDaniel wrote:

Created attachment 1808
Patch

This patch essentially reverts the Cocoa window position coord space to be relative to the top of the main screen. Also fixes a few other Cocoa mouse issues. Note that the ASL_SDL macro is simply a macro we define when building our SDL lib, used to mark our changes to the SDL code.

On 2014-08-09 19:48:24 +0000, Robotic-Brain wrote:

Created attachment 1810
Removed ASL_SDL macro switches

On 2014-08-17 21:59:33 +0000, Sam Lantinga wrote:

Good point. Your patches are applied:
https://hg.libsdl.org/SDL/rev/c5e33f9a0d03

I'm assigning this bug to Jorgen so he can look at [NSWindow constrainFrameRect] and see if that achieves his goals.

On 2015-02-19 02:45:05 +0000, Ryan C. Gordon wrote:

(In reply to Sam Lantinga from comment # 4)

I'm assigning this bug to Jorgen so he can look at [NSWindow
constrainFrameRect] and see if that achieves his goals.

Ping; is there anything we need to do here still, Jorgen? We're triaging for 2.0.4 right now.

--ryan.

On 2015-02-27 00:57:00 +0000, Jørgen Tjernø wrote:

Good question -- not sure when I'll have a chance to look. Mouse coordinates on Mac have always been a PITA in SDL.

On 2018-08-06 21:20:24 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.