I was seeing a crash due to an assert about manipulating it on a
background thread. I can't recall where I was seeing that. I think it's
new in Catalina.
Signed-off-by: Chip Davis <cdavis@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We rely on AppKit-internal events to know when a window is being
dragged. In Catalina, AppKit stopped sending the "drag ended" event when
no drag actually took place, though it still sends "drag started" events
when the title bar is clicked. Ironically, this caused us to think the
window was still being dragged. In that case, waiting for the mouse
button to come back up should allow us to determine when the drag should
end.
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>
D3DKMTSetVidPnSourceOwner needs to be implemented in the graphics drivers
because we need to maintain the VidPN source ownership information list
in the graphics drivers. For example, the graphics drivers need to release the
exclusive ownership when a new window is moved to a monitor which has been taken
exclusive ownership.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This never worked. opengl_funcs.ext.p_<func> would always be NULL at the time
it was checked, so nothing would be changed.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Note that since tiptext is a buffer it cannot be NULL.
Signed-off-by: Francois Gouget <fgouget@free.fr>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
macOS SDKs older than 10.11 doesn't support Metal.
macOS 10.11 and 10.12 SDK support Metal but don't
support registryID in MTLDevice protocol. Recommend
using 10.13+ SDK.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is winemac.drv port of 846a8f6c8d.
Signed-off-by: Akihiro Sagawa <sagawa.aki@gmail.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This sends the expected WM_IME_ENDCOMPOSITION message.
Signed-off-by: Aric Stewart <aric@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Prevents an input lockup in this case.
Signed-off-by: Aric Stewart <aric@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>
App Nap defers timer firings and I/O if the app is not visibly or audibly
updating. An app is supposed to disable it during user-requested or background
activity, but we can't know when the Windows app is engaged in such. Since it's
not generally acceptable for timers or IO to be deferred, we have to disable it
at all times.
The user can re-enable it by setting the following registry setting:
[HKEY\Software\Wine\Mac Driver]
"EnableAppNap"="y"
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This makes the display match that of native apps. For example, the UI of Mac
Steam vs. Windows Steam or a PNG shown in iexplore.exe vs. Preview.
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>
It had only been done when a window is shown. Some games change the display
mode before showing their first window. Following Mac conventions, the Mac
driver does not apply display mode changes when it's not the active GUI app.
If such a game were to change the mode and then query display-mode-related info,
it would get info for the original mode, not the requested mode.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Ken Thomases