- 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 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 3 commits
-
-
Ken Thomases authored
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
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>
-
- 14 May, 2016 1 commit
-
-
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>
-
- 06 May, 2016 1 commit
-
-
Ken Thomases authored
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>
-
- 05 Feb, 2016 1 commit
-
-
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>
-
- 05 Jun, 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.
-
- 20 Jan, 2015 1 commit
-
-
Ken Thomases authored
For some empty RECTs, such as { INT_MAX, INT_MAX, INT_MIN, INT_MIN }, right minus left or bottom minus top underflow and wrap around to positive values.
-
- 24 Apr, 2014 1 commit
-
-
Ken Thomases authored
-
- 21 Mar, 2014 1 commit
-
-
Ken Thomases authored
-
- 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.
-
- 17 Dec, 2013 1 commit
-
-
Ken Thomases authored
In particular, keep the title bar from moving behind the menu bar or Dock (when it's on the bottom).
-
- 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.
-
- 22 Nov, 2013 1 commit
-
-
Ken Thomases authored
winemac: Add support for a "Decorated" registry setting to control whether windows get Mac-style decorations.
-
- 20 Nov, 2013 1 commit
-
-
Huw Davies authored
-
- 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.
-
- 22 Oct, 2013 2 commits
-
-
Ken Thomases authored
winemac: Disable software GL rendering unless it's enabled via a new registry setting, AllowSoftwareRendering.
-
Alexandre Julliard authored
-
- 21 Oct, 2013 1 commit
-
-
Alexandre Julliard authored
-
- 11 Oct, 2013 1 commit
-
-
Ken Thomases authored
Based in large part on a patch submitted by Kevin Eaves.
-
- 08 Oct, 2013 3 commits
-
-
Ken Thomases authored
-
Ken Thomases authored
-
Ken Thomases authored
-
- 30 Sep, 2013 1 commit
-
-
Ken Thomases authored
-
- 27 Sep, 2013 2 commits
-
-
Ken Thomases authored
The Mac driver doesn't normally steal focus, but a press of a hot key counts as the user giving permission.
-
Ken Thomases authored
Partially based on a patch for winex11 previously submitted by Vincent Povirk.
-
- 18 Sep, 2013 2 commits
-
-
Ken Thomases authored
-
Ken Thomases authored
-
- 06 Sep, 2013 1 commit
-
-
Ken Thomases authored
winemac: Add support for mouse-move and right- and middle-click events on systray icons in the Mac status bar.
-
- 21 Aug, 2013 1 commit
-
-
Ken Thomases authored
-
- 09 Jul, 2013 1 commit
-
-
Ken Thomases authored
-
- 02 Jul, 2013 2 commits
-
-
Ken Thomases authored
-
Ken Thomases authored
winemac: Add registry setting to control glFlush() skipping for single-buffer contexts and disable it by default.
-
- 20 Jun, 2013 1 commit
-
-
Ken Thomases authored
... in addition to if one is focused.
-
- 04 Jun, 2013 1 commit
-
-
Ken Thomases authored
This improves the animation of the window unminimizing from the Dock in some cases. The window would often be blank or, for shaped windows, invisible during that animation.
-