Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't minimize windows after running fullscreen #189

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

Can't minimize windows after running fullscreen #189

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 1.2.10
Reported for operating system, platform: Mac OS X 10.4 (PPC), PowerPC

Comments on the original bug report:

On 2006-07-16 16:12:26 +0000, Frank Becker wrote:

When you quit an SDL application while in fullscreen mode, the open windows of other applications start refusing to minimize (their minimize control is grayed out).

Newly opened windows do not suffer from the problem, and running the SDL application again, but quitting it while in windowed mode also fixes the old windows again.

This was introduced in 1.2.10. 1.2.9 is ok.

The related email thread is "OSX: Can't minimize windows after running fullscreen".

On 2006-07-18 15:21:06 +0000, Christian Walther wrote:

Seems I was wrong about newly opened windows not being affected, and running the SDL app again fixing the old ones. I can't reproduce that now - the minimize buttons of old and new windows stay disabled until you close and reopen their application.

So far, I verified that the bug was indeed introduced in revision 1885 with the new fading code. The next step, hopefully tomorrow, will be finding what the exact problem is - it looks like something isn't getting cleaned up properly when you quit out of fullscreen.

On 2006-07-23 07:37:57 +0000, Christian Walther wrote:

Created attachment 151
proposed patch

Wow, that was an interesting bug to chase. It was a timing issue: it seems that for some reason, a certain time must pass between ShowMenuBar() being called in QZ_UnsetVideoMode() and the application quitting. Before rev. 1885, this delay was provided by the slow hand-coded fade. With the asynchronous Core Graphics fading introduced in rev. 1885, that delay was no longer present (most of the time) and the bug became apparent. Adding an SDL_Delay(100) somewhere between ShowMenuBar() and the end of QZ_VideoQuit() lowered the frequency of the bug appearing from "almost every time" to "very rarely" here.

However, there is another solution: doing the ShowMenuBar() before releasing the captured display instead of afterwards. Apparently, no delay is necessary in that case, and it looks nicer to me anyway because it is the reverse order of the way things are set up in the beginning: capture display - set video mode - hide menu bar - ... - show menu bar - reset video mode - release captured display. So, this is what the attached patch does.

In addition, I've taken the liberty of

  • removing some unused code that I forgot to remove in rev. 1885,
  • fixing two warnings about undeclared functions in SDL_QuartzVideo.m by including OpenGL.h (whose name is a bit misleading - it only declares CGL stuff, so there's no interference with SDL_opengl.h).

On 2006-07-30 02:43:19 +0000, Christian Walther wrote:

Any comments? Frank, can you try this?

On 2006-08-02 01:27:25 +0000, Frank Becker wrote:

The patch works for me. Thanks!

On 2006-09-23 21:27:31 +0000, Sam Lantinga wrote:

Thanks Christian, your patch is included in subversion.

Hey, if you want to take a look at SDL 1.3, I could use a hand with the fullscreen code. I don't really know what I'm doing poking around in there. :)

On 2007-04-06 17:53:25 +0000, Mike Blaguszewski wrote:

*** Bug 404 has been marked as a duplicate of this bug. ***

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant