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>
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>
It doesn't seem to work well. In full-screen mode, newly-added windows don't
always properly resize to fill the screen, so they're not the same size as the
windows they're nominally tabbed with. In non-full-screen mode, switching
between tabs sometimes causes the windows to grow in height each time. Etc.
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>
Ideally, user32 would adjust its z-order for window activation as happens on
Windows. Then, the Mac driver would just reflect such changes in the Cocoa
windows. But user32 doesn't do that. SetActiveWindow() and SetForegroundWindow()
just adjust focus and status.
This is an attempt to achieve a similar result.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fixes a problem where the client area view would not be resized as the user
resizes the Cocoa window.
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>
-[NSApplication sendEvent:] seems to consume the event and doesn't pass it along
to the window.
Mac keyboards haven't included a Help key for a long time, but users with PC
keyboards can use the Insert key, which is in the same position. The Mac
driver translates either one to VK_INSERT.
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>
During a call to GetClipboardData(), the app may be asked to render the data
for a promised format. This will cause us to receive WM_CLIPBOARDUPDATE.
Almost always, the app will have just rendered the requested format and not
made any other changes. Therefore, we don't need to rebuild the Mac pasteboard
from the Win32 clipboard. Doing so can cause a race with the other Mac app
which is querying the pasteboard (for a paste operation, for example). We
basically delete the data we _just_ added and rebuild the list of available
types. The symptom is that the other Mac app sees the available types change
and maybe be incomplete.
In theory, the Windows app could make other changes to the clipboard and this
change would cause us to fail to convey them to the Mac pasteboard. I consider
that very unlikely and the tradeoff to improve the common case is worth it.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
With windows, the Cocoa main thread may have changed the frame and messages to
that effect may be in the queue, so it can be important to reassert the
"current" value and discard those messages. With views, by contrast, Cocoa
will never change the frame on its own and there are no messages to discard.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The skipped code is a no-op for the child window case, except that the call to
set_window_surface() synchronizes with the main thread, even with null arguments.
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>
Continue exporting in the original format under org.winehq.registered.HTML Format
for fidelity when copying and pasting within Wine.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
If another app grabbed the clipboard, that most likely happened while it was
active and the Wine process was inactive. Our process being made active again
is a good opportunity to check for that.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When windows aren't full-screen, non-floating windows go in NSNormalWindowLevel
and floating ones go in NSFloatingWindowLevel, which is higher. However, a
non-floating full-screen window will go into a level higher than either of
those. The prior logic of the -adjustWindowLevels: method would keep the
floating windows at a window level at least that high. They should actually
be in a strictly higher level.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes an oversight in commit d91e56863. Some of the views created for
Win32 child windows were being left out of any view hierarchy. OpenGL contexts
attached to such child windows and views were not able to render to screen,
leaving blank areas.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It would eventually get updated by the keyboard changed event, but
only after the message queue was pumped.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Renamed it to macdrv_get_pasteboard_formats(), since the "copy" was meant to
convey Core Foundation ownership semantics which no longer apply.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
… as is done in user32's and gdi32's version of the same function.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The relevant Mac-native types, public.utf16-plain-text and public.utf8-plain-text,
are handled by CF_UNICODETEXT and user32 handles the synthesis of CF_TEXT and
CF_OEMTEXT from that.
CF_TEXT and CF_OEMTEXT are still exported and imported with a Wine-specific
type to preserve cross-prefix copy/paste fidelity.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The relevant Mac-native type, com.microsoft.bmp, is handled by CF_DIB and
user32 handles the synthesis of CF_BITMAP and CF_DIBV5 from that.
CF_BITMAP and CF_DIBV5 are still exported and imported with a Wine-specific
type to preserve cross-prefix copy/paste fidelity.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
At least one Mac app, TextWrangler, puts UTF-16 data on the pasteboard with
lines separated by CR (although it uses LF for the UTF-8 form of the same text).
Other Mac apps handle it properly; we should, too.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Akihiro Sagawa