Re: Cocoa, full-screen mode, and windows
Re: Cocoa, full-screen mode, and windows
- Subject: Re: Cocoa, full-screen mode, and windows
- From: John Stiles <email@hidden>
- Date: Fri, 11 Feb 2005 11:57:50 -0800
On Feb 11, 2005, at 11:46 AM, Ricky Sharp wrote:
On Friday, February 11, 2005, at 01:12PM, John Stiles
<email@hidden> wrote:
OK, now I've got everything running full-screen?I use CoreGraphics to
capture all screens and select the mode I want, and then make an
NSWindow with the proper bounds.
It was explained to me on the quartz-dev list by an Apple engineer
that this is actually a bad thing to do. If you want to use the CG
APIs to capture the display, it's best to then work directly with the
given buffers and not attempt to put up your own window.
I'm not at home right now, but I can send the original e-mail to you
privately.
Even if you're switching resolution? As a game, it's pretty critical
that I have the ability to change resolution at will. Users tend to get
frustrated when a game messes up their window/icon positioning by
changing resolutions. (Though I have to admit, the OS has improved
greatly here since the classic days—it used to cause all sorts of
grief, and nowadays a resolution switch seems to be a lot less
destructive to the desktop environment.)
Because using the AppKit was very important for my needs, I ended up
not capturing the displays, but instead putting up "blanking" windows
on all devices (used the NSScreen APIs to get the list). I then put
up a borderless window centered on the user-selected device.
I also use SetSystemUIMode to hide both the menu bar and Dock.
I could certainly utilize this approach if changing resolutions was
considered OK. It seems to go against the accepted advice of "always
capture if you're going to switch resolutions," though...
About the only "hack" currently in place is that it was best to fudge
the window levels. I believe my blanking windows are at the level
"document plus one" and content window at "document plus two". This
was done for two reasons. Primarily to disallow the blanking window
from moving in front of the content window. Secondarily to work with
Expose as much as possible. Although, I have a bug filed about Expose
still being allowed in certain system UI modes.
Doesn't really sound like a hack to me; that's just keeping things tidy.
Finally, I had to subclass NSWindow since my content window needed to
become key. NSWindow's implementation of canBecomeKeyWindow returns
NO if your window has no title bar. My subclass simply returns YES.
Yeah, I've got one of those set up already :)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden