Cocoa Dos and Don'ts
When writing code using Cocoa, there are rules to follow. Anything that uses Objective-C++ must of course follow the C++ guidelines. However, there are things in Cocoa that are more subtle than they look. Here are a few things to keep in mind.
The use of const NSObjects is prohibited as it makes Clang unhappy. (This is enforced in the presubmit hooks.) See the Mac Clang page for more details.
The use of atomic properties is prohibited. There are differences between how our compilers handle them, and since we don't need them anyway we don't use them. See the Mac Clang page for more details.
Tracking rects are tricky to get right. Apple realized that, and in Mac OS X 10.5 introduced the NSTrackingArea object. Unfortunately, that is also difficult to get right, and has historically led to nasty crashes.
The use of
-[NSView addTrackingRect:owner:userData:assumeInside:] is
The use of raw
NSTrackingAreas is prohibited.
You are required to use
CrTrackingArea. Find it at
ui/base/cocoa/tracking_area.h. There are currently (and unfortunately) lots of
current usage of tracking rects and
NSTrackingAreas. Please convert them as
you encounter them.
There are spots of Cocoa that are tricky. Watch out.
All code that manages views is required to be correct, and that correctness is more heavily tested when running under "resolution independence" or "HiDPI", where window coordinates are not the same as view coordinates. (Turn on resolution independence in Quartz Debug.app.)
Any time you need to compute window coordinates based on view coordinates, or
vice versa, make sure you use the appropriate conversion calls (i.e.
-convertRect:toView: and friends). There is a call for each data type and each
conversion direction. Also, remember that views have both a
-frame. They are in different coordinate systems.
In doing coordinate conversion, you may run into methods on views that convert to and from the "base" coordinate system. Those are almost certainly not what you are looking for. When talking about views, the "base" coordinate system is referring to the raw backing pixels. If you need to precisely align to pixels, they are correct, but most of the time they do not do what you think they are doing.
(This problem is compounded by the references in methods on windows to the "base" coordinate system, which is indeed the window coordinate system.)
The Mac's windowserver has issues with zero-sized windows, spewing tons of junk to the console, yet it's not immediately obvious when you resize them that it's a problem.
Ensure that you do not resize windows to be empty, either implicitly or explicitly.