Someone emailed me tonight with this bug report for Dirk Dashing:

"When I play DD, the yellow minimize buttons on my C2D MacBook are disabled. It's annoying but not a crisis. Once I quit my apps the minimize comes back. This is particularly a problem on Safari where after playing DD, the yellow buttons are grayed out."

I don't see this problem on my PowerBook G4 (running OS X 10.4.2) or my MacBook Pro (running OS X 10.4.8). Has anyone seen this before, or have any ideas what the problem might be (or how to go about solving it)?

Some more info from this person:

"I'm running 10.4.8 Build 8N1106. I play DD in full screen with apps working in the background. When I quit DD after running in full screen , I no longer have any minimize buttons in my other apps. I leave safari open while I'm playing. Just double checked it, by starting the game, then quitting while Safari was open. Minimize buttons died. It also affected Mail, and all my other open Apps. As I said, quitting the app, then restarting gets the minimize button back."

Any ideas what the problem might be?

Minimize buttons disappear when the Dock fails to respond to an Application's request for a while.

I've seen anecdotal evidence that this can happen when you capture the screen but don't hide the menubar. How are you making your full-screen context?

OneSadCookie Wrote:Minimize buttons disappear when the Dock fails to respond to an Application's request for a while.

Sorry, when the Dock fails to respond to what requests?

I've seen this happen before so I'm interested.

Apple does some voodoo behind the scenes (and sometimes expects us to automatically know the magic incantations) that either isn't documented fully or worked out fully all the time. Just today I discovered that CGReleaseAllDisplays() wouldn't release all the displays reliably if I didn't clear the drawable first, but it would sometimes... As far as I've experienced, the whole full screen thing in OS X has been nebulous from the start.

AFAIK, CG display capturing and full-screen OpenGL contexts know nothing about each other, so any supposed relationship between the two seems suspicious...

Full-creen on Mac OS X is *much* better than full-screen on Windows or Linux, simply because we *have* a proper full-screen mode, rather than shoving a borderless window to the front and hoping for the best!

I don't know the details of the plumbing between AppKit/Carbon, the Window Server and the Dock. My guess is that the minimize button is maintained by the Window Server, which is in relatively constant communication with the Dock. When the Dock stops responding ("beachballs") for a while, that communication breaks, and the Window Server goes into Dockless mode, which means that windows can't be minimized.

OneSadCookie Wrote:AFAIK, CG display capturing and full-screen OpenGL contexts know nothing about each other, so any supposed relationship between the two seems suspicious...

I don't get it either, but you probably know something I don't. When I say CGReleaseAllDisplays(); that should be the end of the story -- drop out of fullscreen and back into the OS no matter what ugliness awaits right? The problem I've encountered is that if I do that, once in a while the screen does not release and might even turn black but that's where it stays. I can hit the power button on the machine, it goes to sleep, I hit the keyboard, it wakes up, and the screen gets magically released. I can even toy with it when it does this and put the mouse in the screensaver corner and it goes back to the last GL frame. I've been complaining about these random fullscreen issues for years now. It remains a point of frustration.

[edit] Like I said, today I added CGLClearDrawable(CGLGetCurrentContext()); just before CGReleaseAllDisplays(); and stress testing the scenario has not repeated that hanging black screen. I have not even the slightest clue how those two could be related. I too am much more suspect that it is *my* fault, but I've been working with this same batch of base code for a few years now and I have been unable to identify my error. I'll send you the code if you'd like. [/edit]

[edit2] I edited out earlier language which was in poor taste. [/edit2]

Are you certain the display is still captured?

Even with the display uncaptured, you can have a full-screen OpenGL context writing whatever crap it wants to the screen.

The "disabled minimize button" happened to me after running Dirk Dashing too, although I didn't realize at the time it was related to it (I had a bazillion other apps open).
I had to log out & back in to clear the bug - restarting the Dock would fix it only for a few minutes but then some apps would start to get the minimize button disabled again.

MacBook (1st gen), Intel GMA 950.

Dirk Dashing uses SDL 1.2.11 for window management, event loop, etc. I use SDL_SetVideoMode to change to fullscreen:


Is this a bug in SDL? Do other SDL programs cause this same problem with the minimize button? Or am I doing something wrong? This same code works fine on Windows and Linux, and appears to work on Mac (except for the minimize button bug).

Is there some additional Mac-specific function I need to call? I assumed SDL would do everything that needed to be done to set the video mode correctly.

OneSadCookie Wrote:Are you certain the display is still captured?.

No. Actually, now that you mention it it probably is released because I sometimes get beeps from the keyboard after mousing around and desperately clicking around. Plus the screensaver can come up. The only thing I can figure is that GL was still attached to its fullscreen drawable, which would explain why adding CGLClearDrawable *seems* to have remedied the problem. Again, it's random behavior, maybe happening one time out of ten, which threw me off. I do it if a fatal error has occurred so it's not the same code as my proper full screen toggling code. Just quick and dirty `get me out of this' code, and I thought CGReleaseAllDisplays was all that was purely necessary for that. But as we're discussing it, it is clear now that you're right, the captured display doesn't have anything to do with the full screen gl context. In fact, reading the documentation for CGLSetFullScreen reveals that this was likely the problem in the first place.

GolfHacker: I apologize for accidentally hijacking your thread!

That problem does indeed appear to be an SDL issue.

I posted this bug in the SDL Bugzilla system, #404.

In the meantime, if anyone else has any ideas what I can do to fix this (in case it is not a SDL bug), please let me know.

If my theory is correct, then sticking something like:


after you SDL_SetVideoMode call might do the trick...

OneSadCookie Wrote:If my theory is correct, then sticking something like:

Code:

extern "C" void HideMenuBar(void);
HideMenuBar();

after you SDL_SetVideoMode call might do the trick...

Where is this function defined? What do I have to link against to resolve this symbol?

EDIT: I punched it into Google, and discovered this is a Carbon function. I believe the SDL project type I used is based on a Cocoa application, since there is Cocoa stuff on the link line. Is there an equivalent function in Cocoa I should be calling instead?

Easier to call the carbon one; they should be equivalent.

The Cocoa call is newer (10.3 maybe?) -- [NSMenu setMenuBarVisible:NO]

But if I use the Carbon call, what do I link against?

Forgive my ignorance, I'm still pretty new to Mac development, and I can't figure out from documentation what library or framework this function lives in.