Re: Disabling Hot Corners
Re: Disabling Hot Corners
- Subject: Re: Disabling Hot Corners
- From: Seth Willits <email@hidden>
- Date: Tue, 23 Jul 2013 12:00:49 -0700
On Jul 22, 2013, at 2:39 PM, Jorgen Tjerno wrote:
> Is there a way to disable Hot Corners when an application is active?
Nope.
> The use case for this is in SDL2, where windows created with SDL_FULLSCREEN_DESKTOP create desktop-sized, borderless windows that are topmost, similar to a fullscreen application (but without a mode change and allowing quick Cmd-Tab etc). When this window is active, the Hot Corners that a user have configured still work.
In most cases you should be capturing the mouse and using deltas. When doing that, the mouse cursor doesn't actually move so it can't hit the corners of the screen or click outside the bounds of the window etc. In full screen games where the OS X menubar and Dock are hidden, you don't need to move the mouse to reach them, and there's no "background" to click on to change apps so capturing the mouse and using deltas has no drawbacks.
When in windowed mode though, if the mouse cursor is visible in-game, it's conceivable a user may attempt to move the mouse to click on the menu bar or a background application, but it is of course not actually possible because the real cursor never moves. Meanwhile the in-game cursor is constrained to the bounds of the window so theres also a visual indication that clicking outside of the game is not possible. The downside to this is that the user must *know* that Cmd-Tab is possible.
If, while in windowed mode, you really do want the user to be able to click on the menubar, then you either you must offer some mechanism to exit (and reenter) captured mouse mode (virtual machine software does this for instance), or simply live without the safety from hot corners.
In the case of cross-platform big title games, there typically is never a need to access any menu in the OS X menubar, because all of the games' functions and information are all accessible through the game's menu system. In the case of some more "casual" games that are more platform-friendly, they may want to use SDL and still access the menu bar as well. In either case though, it only ever makes sense to be able to click on a background application or the game's OS X menu bar when a cursor is visible in-game. That offers the easy entry and exit points for capturing the mouse.
TLDR:
- Capture the mouse and use mouse event deltas to avoid hitting any hot corners.
- If the game is not full screen, when the in-game cursor becomes visible, stop capturing the mouse and use the normal mouse events. Hide the Mac cursor when it is within the bounds of the game window, but when it moves outside of the window hide the game cursor and show the Mac cursor.
- When capturing the mouse, always make sure to programmatically move it to the center of the game window otherwise you can have the mouse be locked outside of the window and click events will go to background apps.
See:
CGWarpMouseCursorPosition/CGDisplayMoveCursorToPoint, CGAssociateMouseAndMouseCursorPosition, NSEvent's delta properties
> Using CGDisplayCapture etc also disables Command-Tab and Exposé, which is undesired behavior - we still want the user to be able to dismiss focus.
>
> Is this more appropriate for mac-games-dev@ or quartz-dev@?
The former is a ghost town, and I don't think it's appropriate for the latter.
--
Seth Willits
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden