Commit Graph

128 Commits

Author SHA1 Message Date
Brendan Shanks 32fb017d4a winemac.drv: Remove workarounds for Mac OS X 10.6 and earlier.
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2021-11-18 22:37:18 +01:00
Tim Clem 9913f27862 winemac.drv: Remove extraneous CGEventTapIsEnabled check.
We no longer enable or disable the event tap manually, and it re-enables
itself on kCGEventTapDisabledByTimeout, so this check is not needed.

Signed-off-by: Tim Clem <tclem@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2021-10-20 20:12:10 +02:00
Tim Clem 5e543fee7a winemac.drv: Stop cursor clipping when all windows are minimized.
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>
2021-10-20 20:12:08 +02:00
Tim Clem 325cc98d7d winemac.drv: Simplify cursor clipping code paths.
Centralizes all clipping behavior into -startClippingCursor: and
-stopClippingCursor.

Signed-off-by: Tim Clem <tclem@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2021-10-20 20:12:01 +02:00
Tim Clem a45bb014e8 winemac.drv: Remove now-unnecessary drag stop event on mouse up.
This approach was added by 5cf64084fb to work around changes to
event behavior in macOS Catalina, 10.15. However, more reliable
notification center messages for dragging are available on 10.12+,
making this path unnecessary.

Signed-off-by: Tim Clem <tclem@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2021-09-15 09:44:25 +02:00
Tim Clem bb28d54d08 winemac.drv: Use window drag notifications when available.
When running on macOS 10.12+, there are private notification center
messages we can use to reliably detect when a window is being
dragged by its titlebar. These are less finicky than the current
combination of an undocumented event subtype and a left mouse up.

Signed-off-by: Tim Clem <tclem@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2021-09-15 09:44:22 +02:00
Brendan Shanks 863683342d winemac: Remove unused GetCurrentProcess() call.
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2020-10-12 22:11:09 +02:00
Brendan Shanks 7aa2601f94 winemac.drv: Fix warnings for constants deprecated by macOS 10.12.
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2020-07-27 23:28:16 +02:00
Gijs Vermeulen 4475524e59 winemac: Add default case in isMouseMoveEventType.
Signed-off-by: Gijs Vermeulen <gijsvrm@gmail.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2020-05-13 22:07:32 +02:00
Gijs Vermeulen 8cd44ecf4c winemac: Avoid some compiler warnings.
Signed-off-by: Gijs Vermeulen <gijsvrm@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2019-12-06 22:30:23 +01:00
Chip Davis 5cf64084fb winemac.drv: Also stop dragging if we receive a mouse up event.
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>
2019-12-03 23:11:46 +01:00
Ken Thomases 250944b643 winemac: Disable macOS's App Nap energy-saving feature by default for Wine GUI processes.
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>
2018-07-16 09:20:10 +02:00
Ken Thomases 09bf88092d winemac: Transform the process to a GUI app on an attempt to change the display mode.
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>
2018-05-14 23:51:58 +02:00
Ken Thomases 611c15953e winemac: Scale cursors for Retina mode, now that user32 scales them with DPI.
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>
2017-07-31 22:00:33 +02:00
Ken Thomases 6250eb54fe winemac: Break out of the window-dragging message loop if the window is hidden or destroyed.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2017-06-21 19:15:12 +02:00
Ken Thomases feb19ee669 winemac: Ignore spurious or redundant notifications that the keyboard input source changed.
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>
2017-05-16 12:08:57 +02:00
Ken Thomases 48548812fe winemac: Move the logic for posting a KEYBOARD_CHANGED event if the keyboard type changes into the setter of the keyboardType property.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2017-05-16 12:08:55 +02:00
Ken Thomases e49feb63f4 winemac: Opt out of macOS 10.12's automatic window tabbing feature.
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>
2017-04-24 20:32:20 +02:00
Ken Thomases 49bb11fef2 winemac: Move a window to the front when its Mac title bar is clicked.
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>
2017-04-24 20:31:59 +02:00
Ken Thomases af2690ab06 winemac: Add a category on NSEvent to simplify checking if the Command key (and only that modifier) is pressed for an event.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2017-04-24 20:31:50 +02:00
Ken Thomases 4b8c0d8784 winemac: Send Help key presses directly to the window, bypassing -[NSApplication sendEvent:].
-[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>
2017-04-04 09:42:15 +02:00
Ken Thomases e5a9055dac winemac: Update the clipboard when the process activates.
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>
2016-12-12 19:14:19 +01:00
Ken Thomases 7161df136f winemac: Keep floating windows in a higher window level than non-floating full-screen windows.
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>
2016-12-02 11:43:44 +01:00
Huw Davies c3dbe44347 winemac: Update the keyboard layout data immediately after changing the input source.
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>
2016-10-24 19:42:24 +02:00
Ken Thomases bdbb3514bb winemac: Use a more idiomatic pattern for an autorelease pool around a loop.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2016-06-03 14:39:19 +09:00
Ken Thomases 1c94bf396f winemac: Add support for a high-resolution ("Retina") rendering mode.
When this Retina mode is enabled and the primary display is in the user's
default configuration, Wine gets told that screen and window sizes and mouse
coordinates are twice what Cocoa reports them as in its virtual coordinate
system ("points").  The Windows apps then renders at that high resolution and
the Mac driver blits it to screen.  If the screen is actually a Retina display
in a high-DPI mode, then this extra detail will be preserved.  Otherwise, the
rendering will be downsampled and blurry.

This is intended to be combined with increasing the Windows DPI, as via winecfg.
If that is doubled to 192, then, in theory, graphical elements will remain the
same visual size on screen but be rendered with finer detail.  Unfortunately,
many Windows programs don't correctly handle non-standard DPI so the results
are not always perfect.

The registry setting to enable Retina mode is:

[HKEY_CURRENT_USER\Software\Wine\Mac Driver]
"RetinaMode"="y"

Note that this setting is not looked for in the AppDefaults\<exe name> key
because it doesn't make sense for only some processes in a Wine session to see
the high-resolution sizes and coordinates.

Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2016-05-06 11:45:24 +09:00
Ken Thomases 3d73f62f01 winemac: Use floor() rather than truncation when converting Cocoa event positions to integers.
This is so negative coordinates are adjusted in the same direction as
positive ones (left and up).

Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2016-05-05 13:18:39 +09:00
Ken Thomases e5c120893d winemac: Wrap performing requests from background threads in an autorelease pool.
Cocoa manages an autorelease pool on the main thread, but it only drains it
when it processes an event.  Our requests come through a run loop source, which
doesn't count as an event.  So, autoreleased objects can accumulate when the
app is not being interacted with.

Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2016-02-18 21:05:49 +09:00
Ken Thomases 5c992f9653 winemac: Don't post a WINDOW_BROUGHT_FORWARD event for a click on a window which is already frontmost in its level.
Commit 793ab7d45 fixed a bug where WINDOW_BROUGHT_FORWARD events weren't being
posted when they should, but it caused a regression in Scribblenauts Unlimited.
Every click caused a window ordering operation that generated messages and
Scribblenauts would move the mouse cursor to the upper-left corner of the
window in response.

Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2015-12-01 12:44:19 +09:00
Ken Thomases d8deecab11 winemac: Enable localization of strings used to build Mac menus.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2015-11-17 22:56:39 +09:00
Ken Thomases 4db8fc394d winemac: Cope with multiple seemingly-identical display modes, only some of which work, by trying them in sequence.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2015-11-03 13:48:11 +09:00
Ken Thomases 9d6a14305a winemac: Add another workaround for bad side effects of CGWarpMouseCursorPosition().
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
2015-10-29 10:55:16 +09:00
Ken Thomases 793ab7d457 winemac: Tell Wine when Cocoa brought a clicked window forward even if it sent the click event.
Not sending the brought-forward event for a click that was sent was an artifact
of a time when that branch was only used for posting a request for focus.  When
I added the brought-forward event, I didn't reconsider that logic.
2015-08-13 15:04:35 +09:00
Ken Thomases 792b47ad3b winemac: Restore a maximized window if a user tries to move it by dragging its title bar.
OS X doesn't have the same concept of maximized windows as Windows does.
There's no mode that prevents a normally-movable window from being moved.  If
a window is "zoomed", it mostly fills the screen but the user can still move
or resize it, at which point it ceases to be in the zoomed state.  So, users
are confused and frustrated when they can't move a window that's maximized.

To get similar behavior while still respecting Win32 semantics, we detect when
the user tries to move a maximized window.  When they start, a request is
submitted to the app to restore the window.  Unless and until the window is
restored, we don't actually allow the window to move.

The user expects to move the window from its current (maximized) position.  It
should not jump to its normal position upon being restored.  So, we set the
window's normal position to its current position before restoring it.
2015-03-24 13:55:34 +09:00
Ken Thomases 8ec1b4f010 winemac: Tell Wine that Cocoa brought a window forward even if a window is being dragged.
When a window is being dragged, we prevent delivery of clicks to Wine.  We were
also preventing telling Wine that a window had been brought forward, but this
was incorrect.  It prevented clicks in the title bar from activating the window.
2015-02-02 22:27:35 +09:00
Ken Thomases 5fe3c4b89e winemac: Track which window was brought forward by Cocoa separately from the window receiving the click event.
If the mouse is captured, we change which window receives the click event, but
that shouldn't change which window we tell Wine was brought forward by Cocoa.
2015-02-02 22:27:30 +09:00
Ken Thomases 2b97f8c1d1 winemac: When Cocoa brings a window forward, tell Wine even if it's disabled or no-activate.
We can't prevent Cocoa from bringing disabled/no-activate windows forward.  So,
we need to tell Wine about the z-order change.

We still do avoid telling Wine to activate disabled/no-activate windows, though.
2015-02-02 22:27:19 +09:00
Ken Thomases c3d7f5b7ec winemac: Use new API when available to list all display modes available on Retina Macs. 2014-07-30 11:33:00 -05:00
Ken Thomases 451915100a winemac: Add the ability to disable high-resolution scrolling.
The Mac driver can generate scroll wheel events with values which are not integral
multiples of WHEEL_DELTA.  Apps should handle that by scrolling a corresponding
non-integral multiple of what they'd do for a WHEEL_DELTA-valued scroll or, if
they can't, then at least accumulate scroll distance until its magnitude exceeds
WHEEL_DELTA and do a "chunky" scroll.  However, many apps don't do that properly.
They may scroll way too far/fast or even in the opposite direction.

If the registry setting UsePreciseScrolling is set to "n", the Mac driver will do
that accumulation and chunking itself to work around such broken app behavior.
2014-05-15 11:28:52 +02:00
Ken Thomases 3bca22a6b9 winemac: Don't bring owned windows to the front when they're clicked.
Cocoa will bring an unowned window to the front of its level when it's clicked,
but it doesn't do that for owned windows.  The old code went out of its way to
make owned windows behave like unowned windows in this respect.  That was
exactly backward.  We wish we could control whether windows are raised on a
click.  We don't have that opportunity for unowned windows, but, by ripping
out a bunch of code, we do for owned windows.
2014-05-08 10:24:31 +02:00
Ken Thomases ef4677106a winemac: Disable moving or resizing windows when cursor clipping is in effect.
Many games clip the cursor to the client area of the window.  However, on OS X,
the resizing controls extend into that client area.  So, it's possible that
while playing, the user might unintentionally click in the resizing area and
drag, resizing the window.
2014-04-29 11:22:58 +02:00
Ken Thomases 70c4f43ed3 winemac: Ignore mouse capture during window drags for routing click and move events. 2014-01-29 12:38:52 +01:00
Ken Thomases ce5a87b1ef winemac: Simplify display mode code.
When originalDisplayModes has entries, the app is active.  When the app is
active, latentDisplayModes is empty.
2014-01-10 12:05:41 +01:00
Ken Thomases d4d92a759e winemac: Clear the latentDisplayModes instance variable before realizing the latent modes. 2014-01-10 12:05:38 +01:00
Ken Thomases 42a7d7209b winemac: Restore display mode to original in more cases.
We only care if we have changed the mode and we're changing it back to its
original.  Even if the current mode matches the target mode, we may still
need to release the displays and clear the entry from originalDisplayModes.
2014-01-10 12:05:34 +01:00
Ken Thomases 9c65d672a2 winemac: Don't assume the current display mode is the original if we don't have the displays captured.
Another process may have changed the display mode before we queried the
current mode, so we may be seeing a non-original mode.
2014-01-10 12:05:30 +01:00
Ken Thomases fe1c0ab952 winemac: Don't record original display modes when not the active app.
originalDisplayModes should be used when active, empty when inactive.
latentDisplayModes is used when inactive, empty when active.

The count of entries in originalDisplayModes is used to test whether the
process has the displays captured so adding entries when inactive would give
incorrect results.  This could have led us to mistakenly change the display
mode when we don't have the displays captured.
2014-01-10 12:05:25 +01:00
Ken Thomases 4f9de6bcdf winemac: More thoroughly discard events which have been obsoleted by subsequent Wine- or program-driven changes.
Among other things, this fixes Syberia 2.  That game shows, hides, and then
shows its window.  Hiding it caused a WINDOW_LOST_FOCUS event to be queued.
By the time it was processed, the window was the foreground window again.
In response to being told it had lost focus, the game minimized its window.

Hiding the window should have prevented or discarded the WINDOW_LOST_FOCUS
event since the change was driven from Wine and the Win32 foreground/active
window state would already be correct.  In addition, when the program
re-showed its window and made it foreground, that should have discarded the
event as being out of date.  Now they do.
2013-12-31 12:31:39 +01:00
Ken Thomases 6447e8e75c winemac: Defer adjusting window levels while the process is hidden.
While the process is hidden, it can't get a list of its windows which would
be visible were it not hidden.
2013-12-31 12:31:15 +01:00
Ken Thomases 77f0a63b4f winemac: When ClipCursor() is called redundantly, don't warp the cursor or discard mouse move events.
Fixes a problem in some games which repeatedly (re)establish the same cursor
clipping rect, making it exceedingly difficult to move the camera with the
mouse.
2013-12-17 16:53:44 +01:00