- 10 Mar, 2017 1 commit
-
-
Ken Thomases authored
Sierra (macOS 10.12) changed the behavior of key repeat. In previous versions of macOS, key repeat stops when a modifier key is pressed or released. In Sierra, it does not; it just keeps repeating as newly-modified. On Windows, key repeat stops when a modifier key is pressed, although not when one is released. Some programs depend on this behavior. So, the Mac driver emulates it. Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 02 Sep, 2016 1 commit
-
-
Ken Thomases authored
When a window is shown, it may not have drawn its content into the backing surface, yet. Cocoa will draw the window, starting with its standard light gray background and then the content view. However, the content view won't have anything to draw, yet, though, so the window background is not drawn over. A short while later, usually, the app will paint its content into the window backing surface and Cocoa will be told to redraw the window. This works, but the user can often see the flash of the window background color first. This is especially visible for windows with dark content. Part of the fix is to set the window background to transparent until the content view has actually drawn once since the window was shown. That's not sufficient on its own, though. We had disabled Cocoa's automatic display mechanism for windows and put display on a display-link timer. This meant that the window was not actually cleared to its transparent color. When the window was shown, the Window Server displayed a white backing buffer. It is the app process which should fill that backing buffer with clear color but, because we had disabled auto-display, that wasn't getting done at the same time the window was displayed. It was happening some time after. Again, the result was a visible flicker of white. So, we now temporarily re-enable auto-display just before showing a window. 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>
-
- 10 Nov, 2015 1 commit
-
-
Ken Thomases authored
The change to a CVDisplayLink-driven display mechanism introduced a problem: a Wine process never went completely idle for long periods. The display link would fire for every refresh cycle of the display, waking a CPU from idle and wasting energy. To fix that, I have the display link stop itself when it determines that none of its windows need to be displayed. When a window is subsequently marked as needing display, it either temporarily re-enables Cocoa's normal autodisplay mechanism so that it displays at the end of the current turn of the run loop, or it restarts the display link. It chooses the former if it's been a long time since the window was last displayed so that the display is done more immediately. Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 06 Nov, 2015 2 commits
-
-
Ken Thomases authored
It's redundant with the new CVDisplayLink-driven display mechanism. This reverts commits d55d2ec8 and 94dc91a4. Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
Ken Thomases authored
Some Windows apps cause user32 to flush the window surface much faster than the display refresh rate. The Mac driver only marks its window as needing to be redrawn and lets Cocoa decide how often to actually redraw. Unfortunately, Cocoa redraws each time through the run loop and, since the Mac driver uses a run loop source to convey messages from background threads to the main thread, it redraws after every batch of messages. On some versions of OS X, this excessive drawing provokes synchronization with the window server's buffer swaps, preventing the main thread from being responsive. Even when that doesn't happen, it's wasteful. So, we set our windows' autodisplay property to false so that Cocoa never displays windows itself. Then, we arrange to call -displayIfNeeded once per display refresh cycle using a CVDisplayLink. We maintain one CVDisplayLink per display (on demand), move windows among them as the windows change screens, start them when they acquire their first window, and stop them when they have none left. Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 23 Oct, 2015 1 commit
-
-
Ken Thomases authored
Some apps create a zero-sized window as their "main" window and then create all of the other top-level windows as owned windows with that main window as the owner. The user interacts with these owned windows. When the user attempts to minimize one of these owned windows, the app instead minimizes the zero-sized owner window. When an owner window is minimized, all of its owned windows are hidden. The Mac driver faithfully carries out these window operations. The only visible windows are hidden and the zero-sized window is minimized. This results in an invisible animation of the window down to a slot in the Dock - a slot which appears mostly empty. The invisible window thumbnail is badged with the app icon, but it still looks strange. On Windows, the Alt-Tab switcher uses the image of the owned window to represent the zero-sized owner. This commit attempts to do something similar. It takes over drawing of the Dock icon for minimized, zero-sized window. It grabs a snapshot of one of the owned windows and draws the app badge onto it. Since the owned windows are hidden before the zero-sized owner is minimized and we can't take snapshots of hidden windows, we use heuristics to guess when it may be useful to grab the snapshot. If the user minimizes an owned window from the Cocoa side, we grab that window's snapshot. If an owned window is being hidden and no snapshot has been taken recently, we grab its snapshot on the theory that this may be the beginning of hiding all of the owned windows before minimizing the owner. Unfortunately, this doesn't address the invisible animations when minimizing and unminimizing the zero-sized owner window. Signed-off-by: Ken Thomases <ken@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
-
- 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-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.
-
- 03 Oct, 2014 1 commit
-
-
Ken Thomases authored
NSBezierPath doesn't override the -isEqual: method to actually compare paths, so it just falls back to object identity which, in our case, makes paths seem like they're never equal. Also, memcmp()-ing the rectangle array is almost certainly faster than any general test for equality between two paths.
-
- 29 Apr, 2014 1 commit
-
-
Ken Thomases authored
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.
-
- 24 Apr, 2014 1 commit
-
-
Ken Thomases authored
-
- 31 Dec, 2013 1 commit
-
-
Ken Thomases authored
The -[NSWindow isVisible] method returns FALSE when the process is hidden, but that's not what we need to know in some cases. This fixes full-screen games which minimize their window when they lose focus. Command-Tabbing away hides the process. Because the window was not visible, the code didn't actually minimize it. When switching back to the process, no event was sent to the Wine back-end telling it the window had been restored, so it never resumed drawing to it.
-
- 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.
-
- 15 Nov, 2013 1 commit
-
-
Ken Thomases authored
Cocoa normally maintains the relative position of owned windows with respect to the owner, which differs from Windows.
-
- 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
-
- 30 Sep, 2013 1 commit
-
-
Ken Thomases authored
-
- 27 Sep, 2013 1 commit
-
-
Ken Thomases authored
Cocoa won't order a minimized window out of the screen list using -orderOut:. This leaves a window that should be hidden still visible in the Dock, where it can be unminimized.
-
- 26 Sep, 2013 1 commit
-
-
Ken Thomases authored
winemac: When programmatically focusing a window, don't generate WINDOW_LOST_FOCUS event for previously focused window. That event can confuse things if the program switches focus from A to B and then back to A and then processes events. It will get an event saying that A lost focus in Cocoa, check that A does indeed have current focus in Wine, and so switch focus away from it (to the desktop window). (It then gets an event that B lost focus, but that does nothing at that point.)
-
- 18 Sep, 2013 1 commit
-
-
Ken Thomases authored
-
- 30 Aug, 2013 1 commit
-
-
Ken Thomases authored
This allows the relationship to be restored when the window becomes eligible again.
-
- 09 Jul, 2013 2 commits
-
-
Ken Thomases authored
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.
-
Ken Thomases authored
This reverts commit 0d20ac02.
-
- 28 Jun, 2013 1 commit
-
-
Ken Thomases authored
For keys pressed in combination with Command, -[NSApplication sendEvent:] simply doesn't pass the key-up event through to the window.
-
- 18 Jun, 2013 1 commit
-
-
Ken Thomases authored
-
- 07 Jun, 2013 1 commit
-
-
Ken Thomases authored
winemac: Add an option to capture the displays for full-screen windows in addition to display mode changes. Under HKCU\Software\Wine\Mac Driver, set string value CaptureDisplaysForFullscreen to "y" to enable the new behavior.
-
- 04 Jun, 2013 1 commit
-
-
Ken Thomases authored
Minimizing invisible windows causes weird phantoms to appear in Exposé, the Window menu, and the Dock.
-
- 17 May, 2013 1 commit
-
-
Ken Thomases authored
-
- 14 May, 2013 1 commit
-
-
Ken Thomases authored
-
- 07 May, 2013 1 commit
-
-
Ken Thomases authored
-
- 22 Apr, 2013 1 commit
-
-
Ken Thomases authored
Developed with Aric Stewart.
-
- 02 Apr, 2013 1 commit
-
-
Ken Thomases authored
-
- 25 Feb, 2013 1 commit
-
-
Ken Thomases authored
-
- 18 Feb, 2013 2 commits
-
-
Ken Thomases authored
-
Ken Thomases authored
-
- 07 Feb, 2013 1 commit
-
-
Ken Thomases authored
-
- 05 Feb, 2013 2 commits
-
-
Ken Thomases authored
-
Ken Thomases authored
-
- 28 Jan, 2013 2 commits
-
-
Ken Thomases authored
-
Ken Thomases authored
-