Nevermind, I just realized I used the offStateImage rather than the image property for these menu items. The custom images indeed replace the default images, as expected.

It seems I didn't have a choice, so I renamed the class. I used @compatibility_alias, but I still needed to update the encoding and decoding of objects to maintain backward and forward compatibility . I guess I should have added prefixes to class names in the first place, but Apple may consider using more specific names for its (private) classes as well. "Trace" is very generic.

I meant Sequoia, not Sonoma.

Hi Chen. I too wonder why the binding does not bring back the object's attributes. Here a link to a simple project. https://upoitiers86-my.sharepoint.com/:u:/g/personal/jean_peccoud_univ-poitiers_fr/Eap9s3nnTfZGod0dfcDzhZ4BS6KVlJ-XCChuzsEhQyjpwA?e=YmSvqb To reproduce the issue, just click the "Swap folders" buttons, which reorders two Folder objects in an ordered to-many relationships, then saves the context (see swapFolderPositions: in AppDelegate.m). The name attributes of the folders are bound to two text fields, and you will see a name disappear when a folder is turned into a fault (a message is logged in the console when that happens, since I override willTurnIntoFault.

Update: the to-many ordered relationship doesn't have to point to the same entity for this issue to occur (in my example, the "parent" and "subfolders" can be different entities).

I see these messages in red in the Xcode console every time I click in a text field, even for a template app that only has one textfield. This is extremely annoying.

Of note, objects that turn into faults are those that has no pending changes, that is, those that were not inserted nor removed in/from the ordered collection. I can avoid the issue by making dummy changes to these objects, such that they don't turn into faults during the next save, but I'd like to understand the root cause. Maybe I don't know how to manage ordered collections properly. To insert an object, I use insertObject:inSubfoldersAtIndex and I don't modify other objects of the collection. Should I reorder all objects? The documentation says little about ordered to-many relationships.

I d'like to point out that this message is posted even with a template app that contains nothing else than a text field in the window's content view.

Hi. In case you're still around, I'd like to know what solution you've found to your problem. I too need to draw curves on a view that can be very wide, and a single CALayer cannot handle it (even if drawing is constrained to a small rectangle). My current solution is to use several contiguous CALayers, which is less than ideal...

Strangely, general scrolling performance has not decreased, at least not on my MacBook Pro.

Of note: preparedContentRect is called, but a call to super within the method returns NSZeroRect, which contradicts the documentation where it is said that the rectangle always includes the visible portion of the view. Returning the view's bounds from this method doesn't change anything. No overdraw appears to be performed, the visible rectangle is redrawn at each scroll step. Setting the layerContentsRedrawPolicy to NSViewLayerContentsRedrawNever does nothing to the scrolling behaviour. Again, the visible rectangle is redrawn at each scroll steps. I wonder how appkit does it btw, because with this setting, setNeedsDisplay does not redraw the view (which is expected). To sum up: whatever I do, appkit wants to redraw the visible rectangle during scrolling. This is a regression from macOS 10.0, which at least had copiesOnScroll to avoid doing unnecessary calculations to redraw only the part of the view that becomes visible.

I no longer see these log messages after updating to Xcode 15 / macOS 13.6.

I no longer see this warning posted on the console after updating to Xcode 15. I'm still using Ventura.

Ok, I first thought that all projects were affected, but it turns out that only one was. I just deleted the caches and indexing works again. The issue may not have been related to the Ventura update.

I'm getting the same message when I quit my App during a debug session. That started occurring after some macOS/Xcode update. This message isn't associated with any issue and I confirm that it is posted even when quitting a bare-bones template Mac app.