We understand how much developers value syntax highlighting, so we took our time to make sure we got it right.
This update supports nearly 200 languages, ensuring comprehensive syntax coloring coverage.
I’d like to see support for .plist, .strings, .stringsdict, and .pbxproj files.
Furthermore, the “Text” dialog offers two additional noteworthy customization options[…]
Previously:
NSViews clip their drawing contents to their bounds. That sometimes leads to drawing not displaying the way you want, like the bottom of this Hindi glyph in a FreeForm alert window.
Common places this can occur is with font rendering, shadows, or other sub-view accents, like a badge or a flame on that “hot” item for sale. There are ways to solve this. For example, embed the combined views as siblings in a larger view. However, each technique has its own drawbacks. In this case, combining the enclosing view with a button in a simple horizontal stack doesn’t line up the base lines of the text by default. And now you have another problem to solve.
There is a better way. When linked on macOS Sonoma, most NSViews no longer clip to their bounds by default. Hit testing remains unchanged and is determined by the geometry of the view. Of course, you can override hitTest to change this. Now that a view may draw outside of its bounds, its calculated visibleRect may also extend past its bounds. Review any code that uses visibleRect and adjust accordingly. This also impacts the dirtyRect parameter of the draw function. Specifically, the dirtyRect is not constrained by a view’s bounds.
AppKit reserves the right to pass a dirtyRect that is larger than the view’s bounds. AppKit also reserves the right to subdivide drawing into as many rectangles as it needs. What this means for you is that you should use the dirtyRect to decide what to draw, not where to draw.
See also: the release notes.
Apple announced that a long-present internal property, “clipsToBounds”, is now public. In tandem with this change, they are changing the default value for this property to false for apps that link against the macOS 14 SDK.
[…]
What’s happening here is my custom calendar view is filling the “dirtyRect” with its background color before continuing to draw the rest of its content. Unfortunately, what Apple promised in the excerpt above has come to pass: the dirtyRect encompasses nearly the entire window! So when my calendar view redraws, it is evidently overwriting the “OK” button, as well as a date picker that is supposed to appear below the calendar.
[…]
The fix is relatively simple in this case: because I don’t anticipate the view being very large, and filling a rect is a pretty cheap operation, I simply changed it to fill “self.bounds” instead of “dirtyRect”.
Even though this took my surprise, and even though I do think it’ll be the most pervasive source of 3rd-party bugs in Sonoma, I do think it’s a good change. The collective time wasted working around subtle clipping issues is far greater than the time spent working around this one-time change.
I think best-practice if you have a custom control that doesn’t draw outside its bounds is to set the clipToBounds property to YES, and let the OS decide the optimal rect to hand you like it always did. If you do have a control that draws outside its bounds, then the new behavior makes things much easier—instead of playing games with nested views etc to get more drawing space you can just do it directly in the actual control!
Update (2023-10-30): See also: Core Intuition.
Update (2023-12-19): Andy Lee:
“Recognizes”? “Vastly”? Do most people agree with this? Can someone please point to examples where this change made their life easier? I’m genuinely confused.
