Status items are the things on the right end of the Mac menu bar, like the
clock and volume widget. It turns out that they are displayed at a higher
window level than everything else in the menu bar. For the case where the
displays are not captured for a full-screen window, the window ends up at the
same window level as the status items, and they would sometimes end up on top.
They would draw over the full-screen window and could be clicked.
On high-resolution Retina displays, the OS X window backing store has twice the
pixels as Wine's window backing store. So, our images get scaled up. Core
Graphics had been interpolating/smoothing the image, which resulted in
fuzziness. This tells it not to do that.
I had assumed this wouldn't be necessary since we pass FALSE for the
shouldInterpolate parameter of CGImageCreate() when we create the images.
Apparently, that's not sufficient.
When a window is being dragged, we prevent delivery of clicks to Wine. We were
also preventing telling Wine that a window had been brought forward, but this
was incorrect. It prevented clicks in the title bar from activating the window.
If the mouse is captured, we change which window receives the click event, but
that shouldn't change which window we tell Wine was brought forward by Cocoa.
We can't prevent Cocoa from bringing disabled/no-activate windows forward. So,
we need to tell Wine about the z-order change.
We still do avoid telling Wine to activate disabled/no-activate windows, though.
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.
On Yosemite, in full-screen mode, Cocoa adds child windows of its own to our
windows. These windows are, of course, not instances of WineWindow. So, when
we call WineWindow-specific methods on them, it throws exceptions.
On Yosemite, double-clicking a window's title bar zooms it. (This is to
compensate for the fact that the zoom button has been replaced by a full-screen
button.) Sometimes, double-clicking in the content area would count as double-
clicking in the title bar.
This is controlled, in part, by the -mouseDownCanMoveWindow method of the view
that was hit in the window. The default implementation of that returns YES
for non-opaque views, as the views are in the Mac driver. Overriding it to
return NO prevents the problem.
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.
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.
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.
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.
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.
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.
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.
Its superclass, NSOpenGLContext, only holds a weak reference. The view was
sometimes being deallocated before the context was disposed of, resulting in
crashes.
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.
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.
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.
Ken Thomases