- 03 Oct, 2014 2 commits
-
-
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.
-
Ken Thomases authored
winemac: Don't invalidate the window shadow on every draw if it's merely shaped and not color-keyed or using per-pixel alpha. This avoids flickering and tearing on some versions of OS X during frequent redrawing in a shaped window, such as when scrolling a document in Word 2007. Since we aren't guaranteed that the window surface has updated bits for us to draw, we mark the whole content view as needing redisplay and draw the window's shape in the background color on the first -drawRect: after the shape change.
-
- 06 Aug, 2014 1 commit
-
-
Ken Thomases authored
winemac: When removing the status item for a systray icon, discard any associated events in the queue.
-
- 30 Jul, 2014 1 commit
-
-
Ken Thomases authored
-
- 16 Jul, 2014 1 commit
-
-
Ken Thomases authored
This means the resulting rectangle will be short, but we don't have much choice. Some apps don't cope properly with the one-past-the-end character. For example, Excel 2007 gets stuck in an infinite loop.
-
- 24 May, 2014 1 commit
-
-
Aric Stewart authored
It is more natural for the cursor to be at the end of the selection being composed instead of being at the beginning.
-
- 15 May, 2014 2 commits
-
-
Ken Thomases authored
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.
-
Ken Thomases authored
-
- 08 May, 2014 1 commit
-
-
Ken Thomases authored
Cocoa will bring an unowned window to the front of its level when it's clicked, but it doesn't do that for owned windows. The old code went out of its way to make owned windows behave like unowned windows in this respect. That was exactly backward. We wish we could control whether windows are raised on a click. We don't have that opportunity for unowned windows, but, by ripping out a bunch of code, we do for owned windows.
-
- 01 May, 2014 1 commit
-
-
Alexandre Julliard authored
-
- 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 2 commits
-
-
Ken Thomases authored
-
Ken Thomases authored
-
- 26 Mar, 2014 1 commit
-
-
Hermès Bélusca-Maïto authored
-
- 24 Mar, 2014 2 commits
-
-
Ken Thomases authored
-
Ken Thomases authored
It's not necessary. Unlike with X11, on Mac OS X the pixel format doesn't affect the properties of windows and views. The pixel format is a property of the GL context, which can attach to any view.
-
- 21 Mar, 2014 2 commits
-
-
Ken Thomases authored
-
Ken Thomases authored
-
- 12 Mar, 2014 1 commit
-
-
Aric Stewart authored
-
- 11 Mar, 2014 1 commit
-
-
Ken Thomases authored
-
- 20 Feb, 2014 1 commit
-
-
Aric Stewart authored
-
- 29 Jan, 2014 3 commits
-
-
Ken Thomases authored
-
Ken Thomases authored
-
Ken Thomases authored
-
- 17 Jan, 2014 1 commit
-
-
Ken Thomases authored
-
- 16 Jan, 2014 1 commit
-
-
Ken Thomases authored
-
- 14 Jan, 2014 5 commits
-
-
Ken Thomases authored
Its superclass, NSOpenGLContext, only holds a weak reference. The view was sometimes being deallocated before the context was disposed of, resulting in crashes.
-
Ken Thomases authored
If the context is being made current with its existing view, just update it before making it current.
-
Ken Thomases authored
We clear it if the context or the view is NULL. If the context is non-NULL, we want to disassociate the views of both the current and passed-in contexts, if they differ.
-
Ken Thomases authored
-
Ken Thomases authored
-
- 10 Jan, 2014 6 commits
-
-
Ken Thomases authored
winemac: For ChangeDisplaySettingsEx(), if caller didn't specify, prefer non-interlaced and unstretched modes.
-
Ken Thomases authored
When originalDisplayModes has entries, the app is active. When the app is active, latentDisplayModes is empty.
-
Ken Thomases authored
-
Ken Thomases authored
We only care if we have changed the mode and we're changing it back to its original. Even if the current mode matches the target mode, we may still need to release the displays and clear the entry from originalDisplayModes.
-
Ken Thomases authored
winemac: Don't assume the current display mode is the original if we don't have the displays captured. Another process may have changed the display mode before we queried the current mode, so we may be seeing a non-original mode.
-
Ken Thomases authored
originalDisplayModes should be used when active, empty when inactive. latentDisplayModes is used when inactive, empty when active. The count of entries in originalDisplayModes is used to test whether the process has the displays captured so adding entries when inactive would give incorrect results. This could have led us to mistakenly change the display mode when we don't have the displays captured.
-
- 02 Jan, 2014 1 commit
-
-
Alexandre Julliard authored
-
- 31 Dec, 2013 2 commits
-
-
Ken Thomases authored
winemac: More thoroughly discard events which have been obsoleted by subsequent Wine- or program-driven changes. Among other things, this fixes Syberia 2. That game shows, hides, and then shows its window. Hiding it caused a WINDOW_LOST_FOCUS event to be queued. By the time it was processed, the window was the foreground window again. In response to being told it had lost focus, the game minimized its window. Hiding the window should have prevented or discarded the WINDOW_LOST_FOCUS event since the change was driven from Wine and the Win32 foreground/active window state would already be correct. In addition, when the program re-showed its window and made it foreground, that should have discarded the event as being out of date. Now they do.
-
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.
-