NSWindowStyleMaskNonactivatingPanel is almost exactly the same behavior
as WS_EX_NOACTIVATE on Windows: it prevents the window from activating
the app, but does not prevent it from being focused if the app is
already active.
Signed-off-by: Tim Clem <tclem@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The previous behavior denies any attempt to focus such windows, which
is not in line with how they behave on Windows.
Rename the macdrv_window_state no_activate field to no_foreground
so it more accurately reflects its meaning.
Signed-off-by: Tim Clem <tclem@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This can happen after the window surface has been destroyed.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52231
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
There's no analogous state on Windows, where an app is focused but has no
visible windows, but this seems like the best behavior.
Signed-off-by: Tim Clem <tclem@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We already set up the Window menu and set the relevant bits in
collectionBehavior, but windows must respond YES to
-canBecomeKeyWindow in order to actually be activated by Cmd+`
window cycling.
Signed-off-by: Tim Clem <tclem@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The motivating example is when a newly created window gets moved off the system
menu bar. A program might not be prepared to handle these messages yet.
Fixes a crash in Lord of the Rings online.
Signed-off-by: Jan Sikorski <jsikorski@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Use a top-down DIB for the surface instead of a bottom-up DIB. This
seems to match better with how Core Graphics expects to receive image
data, and allows us to avoid a transform to flip the surface image.
Signed-off-by: Chip Davis <cdavis@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This used to default to false before Catalina, and it still does so when
the application is built with XCode 10 or earlier. When building with
XCode 11 or later Catalina and newer will create a high DPI GL view even
if the window is low dpi. Because we don't adjust glViewport parameters
(and glDrawPixels, etc) we render only to the lower left quadrant.
Signed-off-by: Stefan Dösinger <stefan@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It isn't safe to access the view object from any thread other than the
main thread. In fact, if you try to call vkCreateMacOSSurfaceMVK() from
any other thread, MoltenVK prints out a big, scary warning telling you
not to do this! Instead, get the layer from the view ourselves and pass
that to MoltenVK. Recent versions of MoltenVK can accept either the view
or the layer.
Signed-off-by: Chip Davis <cdavis@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
miniaturize fails to minimize window when NSMiniaturizableWindowMask
style is not set. The style will be restored on window restore (or earlier).
Signed-off-by: Piotr Caban <piotr@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
For programs linked against the macOS 10.14 SDK, Mojave makes all view
hierarchies layer-backed. For views to which OpenGL contexts have been
attached this caused a regression where they sometimes failed to render and
just remain black. Updating the OpenGL context after the framework has
assigned a layer to our view works around the problem. Thanks to Elviss
Strazdins on Stack Overflow for the solution
<https://stackoverflow.com/a/52938517/1312143>.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Adds the following registry options, which configure the Mac driver to
map Command to Ctrl:
HKEY_CURRENT_USER\Software\Wine\Mac Driver\LeftCommandIsCtrl
HKEY_CURRENT_USER\Software\Wine\Mac Driver\RightCommandIsCtrl
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=35351
Signed-off-by: Ricky Zhou <ricky@rzhou.org>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This was originally done to improve performance at the expense of visually-
correct rendering. I've reconsidered that trade-off.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The window being ordered was first put in the correct place and then was moved
to the other end of the children list by the loop that was intended to adjust
the windows strictly between the window and the ancestor.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Cocoa will draw the window frame immediately but if autodisplay of its content
view is disabled, that may leave the content area black briefly. This change
avoids that flicker.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes an issue where some windows (on some systems) would never display
their content area. If they had a title bar, they'd just display that and
nothing else.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The display link may be stopped even if there are associated windows, due to
idleness. So, it may need to be started when a window is added even if it's
not the first window.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
... rather than whether it currently has one.
This is for OpenGLSurfaceMode=behind. In that mode, we need to make the window
transparent wherever a GL-rendered view should not be clipped by GDI-rendered
children or sibling views.
Some apps attach a GL context to the view only temporarily, do some rendering,
and then detach it. But the GL surface remains, with the rendered graphics.
In order for those to show, the window needs to remain transparent even though
none of its views has a GL context currently attached.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The -fire method called by the display link callback also synchronizes on self
(while accessing the windows array). Display link operations use a lock to
synchronize, too, and it's held while the callback is running.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
They shouldn't get a separate space; they should stick with their parent (owner).
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Simply ordering them out leaves the user on the full-screen space, which is now
an empty black screen. Closing the window closes the space, too.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Cocoa doesn't handle the window being ordered out or closed during the
animation well and leaves a ghost window around.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The code had been handling ordering sibling windows relative to each other,
including windows neither of which were child windows. However, it wasn't
properly handling other relationships (e.g. cousins, nieces, uncles, etc.).
The reason this is complicated is that Cocoa keeps child windows in a fixed
relative order to their parent and siblings. The normal -orderWindow:relativeTo:
method doesn't work. One has to remove the children from the parent and re-add
them in the desired order.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Cocoa does this automatically for non-owned windows and informs the back end
via a different mechanism (WINDOW_BROUGHT_FORWARD). However, for owned windows
(child windows in Cocoa parlance), Cocoa does not change their z-order relative
to the owner (parent) or sibling owned windows when clicked. So, we have to
move the window in user32's z-order so that it gets moved appropriately on
screen in response.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Even if the (un)hidden view doesn't have attached GL contexts itself, its
descendants may. It doesn't make sense not to check them just because this
view doesn't have GL contexts.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Sierra (macOS 10.12) changed the behavior of key repeat. In previous versions
of macOS, key repeat stops when a modifier key is pressed or released. In
Sierra, it does not; it just keeps repeating as newly-modified.
On Windows, key repeat stops when a modifier key is pressed, although not when
one is released. Some programs depend on this behavior. So, the Mac driver
emulates it.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Hiding a view seems to semi-detach any attached OpenGL contexts such that
rendering no longer works. There's no GL surface for the view. Calling
-[NSOpenGLContext update] is not sufficient to reattach the context. So,
fully detach the contexts and reattach them.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
There's no reason for them to be synchronous and this improves performance.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We had been posting it when exiting fullscreen mode ended. However, certain
events during exiting could provoke the back-end to assert the window frame as
it knows it, which would be the one from full-screen mode. This would be
handled by the Cocoa thread after exiting full-screen mode. So, the window
would animate to its pre-fullscreen frame and then spontaneously go back to
covering the screen. This would be Windows-style fullscreen rather than
Cocoa-style and there'd be no obvious way to get out.
The problem occurs on macOS 10.12 (Sierra) due to a change in what methods it
calls on the window while exiting fullscreen.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When a window is shown, it may not have drawn its content into the backing
surface, yet. Cocoa will draw the window, starting with its standard light
gray background and then the content view. However, the content view won't
have anything to draw, yet, though, so the window background is not drawn over.
A short while later, usually, the app will paint its content into the window
backing surface and Cocoa will be told to redraw the window. This works, but
the user can often see the flash of the window background color first. This
is especially visible for windows with dark content.
Part of the fix is to set the window background to transparent until the
content view has actually drawn once since the window was shown.
That's not sufficient on its own, though. We had disabled Cocoa's automatic
display mechanism for windows and put display on a display-link timer. This
meant that the window was not actually cleared to its transparent color. When
the window was shown, the Window Server displayed a white backing buffer. It
is the app process which should fill that backing buffer with clear color but,
because we had disabled auto-display, that wasn't getting done at the same
time the window was displayed. It was happening some time after. Again, the
result was a visible flicker of white.
So, we now temporarily re-enable auto-display just before showing a window.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This works around a Cocoa bug that causes an exception and hang if the view is
being re-ordered within its current superview (as opposed to being moved to a
new superview).
This reverts commit 9fbc364ea1 but adds some
conditions around the call to avoid the flicker on platforms where it's
unnecessary.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This avoids a Cocoa bug where, if an app in the background which is not
hidden calls -unhide:, its main menu bar window is brought forward. The
active app hasn't actually been changed. Key events continue to go to
the app in the foreground. But it's confusing to the user when they
look at the menu bar and, if they click in the menu bar, the background
app really will be activated.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Apple added the same enum declaration to their headers, causing a build failure.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Tim Clem