- 18 May, 2023 1 commit
-
-
Brendan Shanks authored
-
- 15 May, 2023 1 commit
-
-
Rémi Bernon authored
And drop the ime_query_char_rect driver user callback.
-
- 12 May, 2023 4 commits
-
-
Rémi Bernon authored
-
Rémi Bernon authored
-
Rémi Bernon authored
-
Rémi Bernon authored
-
- 10 May, 2023 1 commit
-
-
Rémi Bernon authored
-
- 09 May, 2023 1 commit
-
-
Rémi Bernon authored
-
- 05 Apr, 2023 1 commit
-
-
Rémi Bernon authored
-
- 24 Feb, 2023 1 commit
-
-
Huw Davies authored
Introduced by commit a97fd9f2
-
- 22 Feb, 2023 1 commit
-
-
Paul Gofman authored
-
- 12 Dec, 2022 2 commits
-
-
Huw Davies authored
-
Huw Davies authored
-
- 20 Sep, 2022 1 commit
-
-
Jacek Caban authored
-
- 21 Jul, 2022 1 commit
-
-
Jacek Caban authored
-
- 03 Jun, 2022 4 commits
-
-
Jacek Caban authored
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
-
Jacek Caban authored
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
-
Jacek Caban authored
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
-
Jacek Caban authored
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
-
- 02 Jun, 2022 4 commits
-
-
Jacek Caban authored
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
-
Jacek Caban authored
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
-
Jacek Caban authored
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
-
Jacek Caban authored
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
-
- 03 May, 2022 1 commit
-
-
Jacek Caban authored
Signed-off-by: Jacek Caban <jacek@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 07 Apr, 2022 1 commit
-
-
Jacek Caban authored
They are no longer used from PE code. Signed-off-by: Jacek Caban <jacek@codeweavers.com> Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 20 Oct, 2021 1 commit
-
-
Tim Clem authored
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>
-
- 24 Apr, 2017 1 commit
-
-
Ken Thomases authored
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>
-
- 12 Dec, 2016 1 commit
-
-
Ken Thomases authored
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>
-
- 24 Oct, 2016 1 commit
-
-
Ken Thomases authored
Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 05 Feb, 2016 2 commits
-
-
Ken Thomases authored
Most queries are handled even by threads which are otherwise blocked in OnMainThread(). There's a problem with QUERY_IME_CHAR_RECT, though, in that it can be handled before a previously-queued IM_SET_TEXT event, in which case its character range may be out of bounds. Some apps (e.g. Excel 2007) hang due to the bad range. Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
Ken Thomases authored
winemac: Make macdrv_process_text_input() asynchronous and process internal events while awaiting its result. It had been using the synchronous OnMainThread() to submit its work to the Cocoa thread, but only queries are processed while OnMainThread() waits for the work to complete. This led to QUERY_IME_CHAR_RECT queries being processed out of order relative to IM_SET_TEXT events, making the character range out of bounds with respect to the composition string. Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 06 Oct, 2015 1 commit
-
-
Ken Thomases authored
winemac: Queue an event to reassert the WinAPI window position before Cocoa adjusts its position for a display change. When the display mode changes such that the screen height changes, we'd like our windows to keep their position relative to the top-left of the primary screen. That's how WinAPI's coordinate system works and we want the WinAPI position of the window to not change just because the display mode changed. Unfortunately that's not achievable in Cocoa. Cocoa keeps the window stationary relative to the screen it's on, not necessarily the primary screen, and it's sometimes relative to the bottom-left and sometimes the top-left of that screen. So, what we do instead is queue an event to get the back end to reassert the WinAPI position of the window. This is queued before Cocoa can adjust the Cocoa position of the window which would queue a WINDOW_FRAME_CHANGED to the back end and mess up the WinAPI position. The back end's reassertion of the WinAPI position won't be processed by the Cocoa thread until after Cocoa has adjusted the position and will thus override it. It will also discard any wrong WINDOW_FRAME_CHANGED that may have been queued. Signed-off-by: Ken Thomases <ken@codeweavers.com>
-
- 24 Mar, 2015 1 commit
-
-
Ken Thomases authored
OS X doesn't have the same concept of maximized windows as Windows does. There's no mode that prevents a normally-resizable window from being resized. 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 resize a window that's maximized. To get similar behavior while still respecting Win32 semantics, we now let the user try to resize maximized windows. (The resize cursors are shown at the edges of the window frame.) 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 change its size. The user expects to resize 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.
-
- 24 Apr, 2014 1 commit
-
-
Ken Thomases authored
-
- 30 Dec, 2013 2 commits
-
-
Ken Thomases authored
The user is prevented from moving or resizing a maximized window. The zoom button is still present and enabled for a maximized window but requests that it be restored rather than simply resizing it, which is what it does for normal windows. If a window is not resizable (lacks WS_THICKFRAME) but has a maximize box (WS_MAXIMIZEBOX), then the zoom button requests that it be maximized rather than resizing it.
-
Ken Thomases authored
This also changes to posting rather than sending WM_SYSCOMMAND/SC_MINIMIZE.
-
- 12 Dec, 2013 1 commit
-
-
Ken Thomases authored
winemac: Send WM_{ENTER, EXIT}SIZEMOVE before/after window dragging and run an internal event loop during. This simulates some of what would happen if user32 were managing the drag. The click in the caption would cause WM_SYSCOMMAND/SC_MOVE. The processing of that message is synchronous and doesn't return until the move is complete. Some games require that "blocking" in the internal event loop to prevent them from misbehaving during the drag.
-
- 01 Nov, 2013 1 commit
-
-
Ken Thomases authored
Queries can be run out of order because the main thread is waiting on the response. The main thread didn't really need a response from QUERY_RESIZE_END. It was only a query for symmetry with QUERY_RESIZE_START.
-
- 11 Oct, 2013 1 commit
-
-
Ken Thomases authored
Based in large part on a patch submitted by Kevin Eaves.
-
- 08 Oct, 2013 1 commit
-
-
Ken Thomases authored
-