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>
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.
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.
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.
The code had previously set the cursor back to the standard arrow and unhid
it when it left all app windows. Now it restores the cursor image that the
app set and re-hides it if necessary when it moves back over any app window.
The Mac driver captures the displays when the program changes the display
mode. If the user types Command-Tab to switch away, it resets the displays
to their original modes and releases them. However, if they switched back,
it didn't restore the mode to what the program had set, so the program often
showed the game window in a corner of the screen with the top behind the Mac
menu bar.
For keys pressed in combination with Command, -[NSApplication sendEvent:]
simply doesn't pass the key-up event through to the window. We have to
track which keys we've told Wine are pressed because Cocoa may consume
key-downs that trigger menus or system behaviors.
This fixes an issue with sub-pixel-precise pointing devices on Lion and later.
Wine's notion of the cursor position would get out of sync with the actual position
because deltas don't convey the actual movement distance.
Ken Thomases