[Bug 33467] New: Cannot bring Mac application in front of a Wine application in full screen mode
http://bugs.winehq.org/show_bug.cgi?id=33467
Bug #: 33467 Summary: Cannot bring Mac application in front of a Wine application in full screen mode Product: Wine Version: 1.5.28 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv AssignedTo: wine-bugs@winehq.org ReportedBy: ovvldc@gmail.com Classification: Unclassified
In Wine 1.5.27, I could use cmd-tab to switch to another application and it would pop in front of the application that I am running in Wine in full screen (e.g. a walkthrough for a game, or a manual for a productivity app).
In Wine 1.5.28, I can switch using cmd-tab, and that will make the dock and menu bar appear, but I cannot get the window of another application to come up in front.
Haven't tested 1.5.29 yet, but from the look of the commits, I doubt that this will have changed (none seem to be about fullscreen or windows in the Mac driver).
I cannot do regression tests and say which commit is the problem, but several commits were made by Ken Thomases in the 1.5.28 timeframe that look like they touch on windows and/or positions.
http://bugs.winehq.org/show_bug.cgi?id=33467
Oscar van Vliet ovvldc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
--- Comment #1 from Oscar van Vliet ovvldc@gmail.com 2013-04-26 16:39:00 CDT --- adding regression keyword because it was working fine.
http://bugs.winehq.org/show_bug.cgi?id=33467
Michael Stefaniuc mstefani@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ken@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=33467
--- Comment #2 from Ken Thomases ken@codeweavers.com 2013-04-27 12:51:59 CDT --- Were you using the Mac driver in Wine 1.5.27? It wasn't the default then, so you would have had to go out of your way and edit a registry key.
The Mac driver was turned on by default in 1.5.28. That, rather than any change to the Mac driver itself, is probably what caused the change. You can check by reverting to Wine 1.5.27 but enabling the Mac driver. That entails creating the registry key HKEY_CURRENT_USER\Software\Wine\Drivers and, within that, create a string value named "Graphics" with the value "mac".
However, I think the behavior is correct. The full-screen program has set its window to have the WS_EX_TOPMOST style, so it's supposed to put it in front of all windows which don't have that style. The Mac driver implements this by putting the window at the "floating window" level. So, only other floating windows can come in front of it.
It is important that the Mac driver implement WS_EX_TOPMOST as a floating window because not all such windows are full-screen. For example, an app might create a topmost "palette" that should be visible and accessible even in front of other apps. It is arguably a bug in XQuartz that it doesn't support this mode of operation.
A relevant question, which I'm not sure you can answer, is what those same full-screen programs do on Windows when you Alt-Tab away from them. If they change their window's style, minimize the window, hide it, or something like that, then we should make sure that they do the same under the Mac driver. However, many full-screen Windows programs either don't allow you to Alt-Tab away or don't behave any better than what you're describing.
As a possible feature request, we can consider adding a registry key that would change the behavior of the Mac driver so that it demotes windows back to normal when you switch to another app, but the default should probably still be to honor the window style.
Lastly, as a workaround, you can hide the relevant Wine process. This is complicated by the fact that the Mac driver doesn't currently put a "Hide" item in its Mac application menu. That's on the to-do list for the Mac driver. In the meantime, you can use the Dock menu or the Command-Tab application switcher to hide an app (while the switcher is showing, highlight the app, and press the H key).
http://bugs.winehq.org/show_bug.cgi?id=33467
Oscar van Vliet ovvldc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Linux |Mac OS X Severity|normal |enhancement
--- Comment #3 from Oscar van Vliet ovvldc@gmail.com 2013-04-27 15:50:52 CDT --- I had activated the 1.5.27 Mac driver through the registry, so that is not the issue. I am using Snow Leopard, by the way. It could be that the fullscreen modes in Lion and Mountain Lion are different, but I am not in a position to check.
I understand your reasoning on the topmost floating window. I checked Quicktime, which has it as you describe (return to windowed mode when you cmd-tab). I also checked VLC, which just stays fullscreen, but goes behind what you just activated. VLC obviously has non-standard Mac behaviour, so I am not sure that is a good one.
I am not in a position to check lots of Windows programs right now, but I would agree with your assessment from previous experience.
I am changing this bug report to an enhancement request, as you suggested, because I would still like to be able make the 1.5.27 behaviour standard. Thanks also for the workaround of cmd-tab followed by h.
http://bugs.winehq.org/show_bug.cgi?id=33467
--- Comment #4 from Ken Thomases ken@codeweavers.com 2013-04-27 17:14:44 CDT --- I do most of my development and testing on Snow Leopard so, if there's any difference between the behavior on different versions, the Snow Leopard behavior is most likely to be what I intended. :)
I'm surprised there is a difference in the Mac driver's behavior between Wine 1.5.27 and 1.5.28. The only commit that I see that happened in there that might possibly affect this is commit 2e226b9ad8cd86b4ad6b5a73effa9fa7d5d03958. Are you able to test Wine 1.5.28 with that commit reverted? I'm just curious at this point to know what might have changed the behavior.
I will also put the enhancement request on my to-do list. I needed to add the infrastructure for registry settings to control Mac driver behavior, anyway. :)
http://bugs.winehq.org/show_bug.cgi?id=33467
--- Comment #5 from Oscar van Vliet ovvldc@gmail.com 2013-04-28 07:18:05 CDT --- Thanks so much! Having this option in the registry would be perfect.
I am unfortunately not in a position to put a complete Wine tree and space for compilation on my MacBook, so I cannot test reverting a single commit. Hopefully, when I get a new Mac over the summer I will have space for it and the time to learn how that works. But I hope it will not be very complex to pick up this request, and that you will not struggle with the Mac driver until summer.
I was also thinking that there is some consistency of expectations involved: If I can cmd-tab, I would want to be able to se the application I cmd-tabbed to. And in Mac applications, it is usually possible to do this. In some ways, this is what I used in the functionality of the virtual desktop that was in the XQuartz driver.
Conversely, if the app will not let me show anything else, I shouldn't be able to cmd-tab out of it. This is like the old fullscreen behaviour in XQuartz and would mimic Windows behaviour better, but it also makes getting out of anything that crashes more difficult, and kills any multi-tasking possibilities (and as much as it may improve immersion, I personally think this behaviour is a relic of MSDOS times).
And before I forget again: Thanks for all your hard work on the Mac driver. I am very pleased with it, and it matured impressively quickly.
http://bugs.winehq.org/show_bug.cgi?id=33467
--- Comment #6 from Ken Thomases ken@codeweavers.com 2013-04-28 13:37:47 CDT --- OK, if you can't run that test yourself, can you tell me what full-screen programs have exhibited the change in behavior between 1.5.27 and 1.5.28? If I have access to them, I can test them myself.
http://bugs.winehq.org/show_bug.cgi?id=33467
--- Comment #7 from Oscar van Vliet ovvldc@gmail.com 2013-04-28 13:47:51 CDT --- I had it in Dragon Age: Orgins, but I could try other full-screen applications if you want.
http://bugs.winehq.org/show_bug.cgi?id=33467
--- Comment #8 from Ken Thomases ken@codeweavers.com 2013-04-28 20:49:12 CDT --- It turns out the change wasn't in the Mac driver at all. WineD3D changed from merely putting a normal window on top to using a topmost (floating) window:
Commit: 6ab0ff5b9d2c681246257787da9f3fa4c9268b95 URL: http://source.winehq.org/git/wine.git/?a=commit;h=6ab0ff5b9d2c681246257787da...
Author: Sam Edwards CFSworks@gmail.com Date: Sun Mar 31 18:25:18 2013 -0600
wined3d: Make fullscreen windows use HWND_TOPMOST instead of HWND_TOP.
Unfortunately, that means this new behavior will be more widespread and problematic.
http://bugs.winehq.org/show_bug.cgi?id=33467
--- Comment #9 from Ken Thomases ken@codeweavers.com 2013-04-28 20:57:19 CDT --- Oh, I should also note for posterity that this only affects full-screen games running at full resolution. If the game switches resolution, then the displays are captured and Command-Tab behaves differently. When the displays are captured, the OS doesn't handle Command-Tab. The keystroke is received by the Mac driver, which releases the capture and hides itself (roughly as a means of switching to the next app).
Because of this, you can access your other apps just fine.
When you switch back to the Wine process, it shows but doesn't automatically recapture the display nor change the resolution back. Ideally, the Windows game should do that, but not all do. So, it often ends up showing in just a corner of the screen with the Mac menu bar and Dock visible. Some day I may make the Mac driver recapture the displays and restore the game's chosen resolution.
http://bugs.winehq.org/show_bug.cgi?id=33467
--- Comment #10 from Oscar van Vliet ovvldc@gmail.com 2013-04-28 23:57:26 CDT --- OK, thanks for investigating this all the way!
http://bugs.winehq.org/show_bug.cgi?id=33467
--- Comment #11 from Ken Thomases ken@codeweavers.com 2013-05-29 09:28:17 CDT --- I have submitted http://source.winehq.org/patches/data/96531 which fixes this in my testing. It makes it so that full-screen windows don't float when you switch to another app.
http://bugs.winehq.org/show_bug.cgi?id=33467
--- Comment #12 from Oscar van Vliet ovvldc@gmail.com 2013-05-29 14:28:20 CDT --- Very cool, thanks!
I'll add a comment if it doesn't work like I would expect it, but consider this solved if you don't hear from me in the next few weeks.
Thanks again!
http://bugs.winehq.org/show_bug.cgi?id=33467
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |frederic.delanoy@gmail.com Resolution| |FIXED
--- Comment #13 from Frédéric Delanoy frederic.delanoy@gmail.com 2013-06-18 07:57:40 CDT --- (In reply to comment #12)
Very cool, thanks!
I'll add a comment if it doesn't work like I would expect it, but consider this solved if you don't hear from me in the next few weeks.
Thanks again!
Presumed fixed.
Feel free to reopen if the problem persists.
http://bugs.winehq.org/show_bug.cgi?id=33467
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #14 from Alexandre Julliard julliard@winehq.org 2013-06-21 13:32:51 CDT --- Closing bugs fixed in 1.6-rc3.
-
wine-bugs＠winehq.org