- 20 May, 2021 1 commit
-
-
Rémi Bernon authored
Which creates an off-screen window surface for top-level non-layered or SLWA-layered windows. Signed-off-by: Rémi Bernon <rbernon@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 17 May, 2021 1 commit
-
-
Rémi Bernon authored
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 30 Oct, 2020 1 commit
-
-
Zhiyi Zhang authored
Equivalent of cfcc2809 for winex11.drv. Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com> Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 23 Mar, 2020 1 commit
-
-
Rémi Bernon authored
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=46857Signed-off-by: Rémi Bernon <rbernon@codeweavers.com> Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 10 Jun, 2019 1 commit
-
-
Zhiyi Zhang authored
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com> Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 16 Aug, 2018 1 commit
-
-
Michael Stefaniuc authored
Signed-off-by: Michael Stefaniuc <mstefani@winehq.org> Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 06 Jul, 2018 1 commit
-
-
Zebediah Figura authored
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com> Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 27 Nov, 2017 1 commit
-
-
Ken Thomases authored
Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 29 Jun, 2017 1 commit
-
-
Huw Davies authored
Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 21 Jun, 2017 1 commit
-
-
Ken Thomases authored
Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 24 Apr, 2017 3 commits
-
-
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>
-
Ken Thomases authored
winemac: Move the window to the front of the z-order in SetFocus if it's the foreground window and not already in the front. 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>
-
Ken Thomases authored
winemac: Sync the frame of the Cocoa view for a window's client area while handling a frame-changed event. 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>
-
- 19 Apr, 2017 1 commit
-
-
Piotr Caban authored
Signed-off-by: Piotr Caban <piotr@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 01 Feb, 2017 2 commits
-
-
Ken Thomases authored
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>
-
Ken Thomases authored
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>
-
- 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>
-
- 02 Dec, 2016 1 commit
-
-
Ken Thomases authored
This fixes an oversight in commit d91e5686. 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>
-
- 24 Oct, 2016 1 commit
-
-
Ken Thomases authored
Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 04 Oct, 2016 1 commit
-
-
Hadrien Boizard authored
Signed-off-by: Hadrien Boizard <h.boizard@gmail.com> Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 02 Sep, 2016 1 commit
-
-
Ken Thomases authored
Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 25 Aug, 2016 1 commit
-
-
Piotr Caban authored
Signed-off-by: Piotr Caban <piotr@codeweavers.com> Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 03 Jul, 2016 1 commit
-
-
Piotr Caban authored
Signed-off-by: Piotr Caban <piotr@codeweavers.com> Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 14 May, 2016 4 commits
-
-
Ken Thomases authored
winemac: When a child window's client area is equal to its whole area, use a single Cocoa view for both. This should be a common case and will reduce the number of Cocoa views. Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
Ken Thomases authored
This only really affects OpenGL child windows. GDI rendering to the window surface is still only blitted to the window's content view. The descendant views don't draw and so are transparent, letting the content view show through. Using Cocoa views for child windows fixes a problem where changes to the position and visibility of child GL windows didn't properly affect the Cocoa GL view. Hiding, showing, and moving the top-level window affected the Cocoa window and thus, indirectly, the GL view. Moving the child GL window itself was propagated to the GL view, so that worked. But hiding, showing, or moving any of the intervening ancestors of the child GL window didn't properly affect the GL view. Neither did hiding or showing the child GL window itself. This also slightly improves the clipping of the GL view by its ancestors, although it still doesn't work quite right due to Cocoa bugs. There are also remaining bugs with z-order among multiple GL views and clipping by overlapping siblings. I hope to eventually fix those using Core Animation layers, for which this is a prerequisite. Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
Ken Thomases authored
Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
Ken Thomases authored
Minor no-op refactoring that makes subsequent commits cleaner. 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>
-
- 17 Jul, 2015 1 commit
-
-
Piotr Caban authored
-
- 12 May, 2015 1 commit
-
-
Ken Thomases authored
-
- 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.
-
- 13 Nov, 2014 1 commit
-
-
Huw Davies authored
-
- 01 May, 2014 1 commit
-
-
Alexandre Julliard authored
-
- 24 Apr, 2014 1 commit
-
-
Ken Thomases authored
-
- 21 Mar, 2014 1 commit
-
-
Ken Thomases authored
-
- 29 Jan, 2014 2 commits
-
-
Ken Thomases authored
-
Ken Thomases authored
-
- 17 Jan, 2014 1 commit
-
-
Ken Thomases authored
-
- 31 Dec, 2013 1 commit
-
-
Ken Thomases authored
winemac: For WINDOW_DID_UNMINIMIZE events, don't attempt to restore windows which aren't minimized and visible. The Win32 window state might have changed while the event was in the queue, making it obsolete. Sending WM_SYSCOMMAND/SC_RESTORE might re-show a hidden window, for example.
-
- 30 Dec, 2013 1 commit
-
-
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.
-