Alex Szpakowski
Patch to fix the y component of the position of fullscreen windows in OS X.
In Mac OS X with the latest Mercurial code, when a window is in exclusive-fullscreen the y component of its position is offset by the same amount that is normally taken up by the menubar, resulting in a black bar at the top of the screen.
The recent changes to the internal ConvertNSRect function make it treat the bottom of the menubar as 0 for the y component of window positions, even when the window is fullscreen and 'above' the menubar.
I have attached a patch which fixes the issue by only making the window position relative to the menubar in windowed modes.
Eric Wasylishen
Steps to reproduce:
- Run testwm2 app in the SDLTest Xcode project
- Press Control+R to enable relative mouse mode. The mouse cursor should disappear.
- Press Control+Enter to enter fullscreen.
- Expected: a black screen with no cursor visible. Observed: a black screen, but the mouse cursor is visible in the middle of the screen. It doesn't move when I move the mouse.
Reproduced with latest sdl2 hg (changeset 29aac8b813d9) on OS X 10.9.2. Can't reproduce the problem on OS X 10.6.8 or 10.7.5.
I'm speculating that this really an Apple bug.. but anyway, the attached workaround seems to fix it for me, and I think it's fairly safe.
A more obvious idea, sticking a call SDL_SetCursor(NULL) at the end of Cocoa_SetWindowFullscreen, didn't work.
Eric Wasylishen
The problem seems to be the spaces handling code in -setFullscreenSpace: (SDL_cocoawindow.m) is incorrectly reporting that the SDL_WINDOW_FULLSCREEN -> windowed transition has already happened.
i.e. I saw this case was getting hit when trying to leave SDL_WINDOW_FULLSCREEN:
"else if (state == isFullscreenSpace) {
return YES; /* already there. */
}"
With the attached patch, both Control+Enter (SDL_WINDOW_FULLSCREEN toggle) and Option+Enter (SDL_WINDOW_FULLSCREEN_DESKTOP toggle) work in an sdl test app (I tried testwm2). Tested on OS X 10.9.2.
snake5creator
When starting application with the usual "double click on file" method on Windows, only holding the last click, an unnecessary MOUSEBUTTONDOWN event is sent before the initial MOUSEMOTION event, and mouse button state is stuck in the sense that it takes a subsequent button release, followed by another press for the system to resume sending events (beginning with the next button release / MOUSEBUTTONUP event).
Input event log with held double-click startup: http://i.imgur.com/nypGKR2.png
Without: http://i.imgur.com/yaIqAvV.png
From Melesie
I noticed that when user switches from fullscreen mode to windowed mode and exits application while in windowed mode, Windows performs an additional change of display settings, even though desktop resolution is the same as current one. This causes short black screen to show up. The only way I know of avoiding this is to explicitly switch to default display settings found in registry. MSDN documentation for ChangeDisplaySettingsEx states:
Passing NULL for the lpDevMode parameter and 0 for the dwFlags parameter is the easiest way to return to the default mode after a dynamic mode change.
This would have been a one-line patch to the documentation (specifying that
captures only work as long as the left mouse button is pressed), but I didn't
like that, so I got a little crazy about this instead.
There were several good arguments for this: it's how Windows works with
WM_NCHITTEST, SDL doesn't need to manage a list of rects, it allows more
control over the regions (how do you use rects to cleanly surround a circular
button?), the callback can be more optimized than a iterating a list of
rects, and you don't have to send an updated list of rects whenever the
window resizes or layout changes.
This should be a "long" which on a 64-bit system is likely to be > 32-bits,
causing XGetICValues() to write past the end of the variable (and stack).
Fixes Bugzilla #2513.
