Cocoa would automatically do this for a normal app. However, the Mac driver
makes all of its windows inherit from NSPanel and Cocoa ignores panels for
this feature.
They show up in the taskbar on Windows 7. Selecting them from there is
meaningful and useful, as is selecting them from the Window menu.
In addition to just switching among windows from that menu, this is also
important to recovering a minimized window if the user has configured their
system preferences to minimize windows into the process's dock icon (rather
than as separate dock icons).
The Mac driver captures the displays when the program changes the display
mode. If the user types Command-Tab to switch away, it resets the displays
to their original modes and releases them. However, if they switched back,
it didn't restore the mode to what the program had set, so the program often
showed the game window in a corner of the screen with the top behind the Mac
menu bar.
Cocoa won't order a minimized window out of the screen list using -orderOut:.
This leaves a window that should be hidden still visible in the Dock, where
it can be unminimized.
That event can confuse things if the program switches focus from A to B and
then back to A and then processes events. It will get an event saying that
A lost focus in Cocoa, check that A does indeed have current focus in Wine,
and so switch focus away from it (to the desktop window). (It then gets an
event that B lost focus, but that does nothing at that point.)
This matches what Cocoa does when determining how to handle an event so that,
for example, our test if a click is in the window grow box corresponds to
whether Cocoa will run an internal mouse-tracking loop to resize the window
when we pass it the event. This fixes a problem where both Cocoa and user32
would try to run a resize loop and the cursor would get "stuck" resizing the
window after the button was released.
It's fairly common in Mac keyboard layouts that, if you type a dead key twice,
the second key press will both produce a non-dead character and also
perpetuate the dead-key state. For example, with the U.S. layout, Option-E,
E will produce "" and Option-E, Option-E, E will produce "". Windows
keyboard layouts don't tend to do this. The second key press produces the
non-dead character and clears the dead-key state.
The Cocoa parent-child relationship has undesirable side effects and bugs. In
the general case, it's the only way to maintain the z-order of owned windows
relative to their owner. But when the owner is non-topmost and an owned
window is topmost, the Cocoa window level will enforce that and we don't
need it.
It may be necessary to reorder to some extent because the clicked window is
behind a sibling at the same level, but that shouldn't move it later in the
list than higher-level siblings.
Cocoa gets buggy if the list of child windows isn't in z-order.
The right place may not be the end of the list of Cocoa child windows if some
of the siblings are at a higher window level (i.e. floating if the clicked
window is not).
For keys pressed in combination with Command, -[NSApplication sendEvent:]
simply doesn't pass the key-up event through to the window. We have to
track which keys we've told Wine are pressed because Cocoa may consume
key-downs that trigger menus or system behaviors.
Ken Thomases