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>
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>
This is winemac.drv port from winex11.drv.
Please refer to b8dc1e7cde.
Signed-off-by: Akihiro Sagawa <sagawa.aki@gmail.com>
Signed-off-by: Aric Stewart <aric@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When they were always 32x32, treating that size as though it were in Cocoa's
virtual "points" rather than pixels produced good results even though it wasn't
really correct.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
In particular, when an input method for an Asian language (e.g. Pinyin) is
selected, we were getting repeated notifications. Querying the selected input
method upon receiving them suggested that the keyboard layout changed to U.S.
then back to Pinyin, then several redundant notifications with no apparent
change.
Since the handler for the posted KEYBOARD_CHANGED events sends WM_CANCELMODE to
the active window, this was having bad effects.
The spurious notifications can be distinguished by there being no current
text input context or client. To detect redundant notifications, we track the
last keyboard input source and keyboard layout input source and compare with
the new ones to see if they really changed.
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>
Akihiro Sagawa