Thanks, that link mentions this exact use case.

Sorry, perhaps I wasn't entirely clear. I know about app sandboxing. What I meant is that when selecting ~/Library in an open panel, I would expect to get access to every subfile and subfolder, just like when selecting any other folder. Instead, trying to access ~/Library/Mail (and other folders) as a result of scanning the files contained in ~/Library gives the error I mentioned. Only when selecting these folders explicitly in an open panel there are no errors when trying to access them.

I tried this implementation to autosave changes before quitting the app, but it doesn't work since NSDocument.hasUnautosavedChanges is unexpectedly false. I now get the impression that perhaps a document would be saved automatically before quitting, but there is an issue with how NSTextView marks a document as edited. I would appreciate any insight into this issue. func applicationShouldTerminate(_ sender: NSApplication) -> NSApplication.TerminateReply { let edited = documents.filter({ $0.hasUnautosavedChanges }) if edited.isEmpty { return .terminateNow } var remaining = edited.count for document in edited { document.autosave(withImplicitCancellability: false) { [self] error in if let error = error { presentError(error) } else { remaining -= 1 if remaining == 0 { NSApp.reply(toApplicationShouldTerminate: true) } } } } return .terminateLater }

With the system monospaced font it seems to work, regardless whether I use the window width or height to calculate the font size. On the other hand, with the standard system font, it doesn't work with either width or height. I thought the font size is related to the height, in which case using a monospaced font (where characters have equal width) should make no difference.

size(withAttributes:) returns CGSize not a number. Why wouldn't you calculate newSize = actualSize * newWidth / pastWidth instead? But that's the same as calculating newSize = newWidth * constant, which as I showed doesn't work.

That's exactly the question: how do I adapt the size to fit the window width? I don't see how size(withAttributes:) would help me finding out the correct font size with a single call.

Also when setting SCStreamConfiguration.includeChildWindows = true it’s currently not possible to capture the image of the correct size (i.e. in full resolution).

Thanks, that seems to work. I would have preferred not having to rewrite the various pieces of code that update the table view, but at least we have a workaround.

[quote='853894022, DTS Engineer, /thread/784984?answerId=853894022#853894022'] On macOS, a user can kill an app in different ways [/quote] I don't expect the document changes to be saved when the user intentionally kills the app, but I would expect that when the app is quit normally via the main menu or keyboard shortcut Command-Q, the pending changes would be saved. Are such changes really intended to be discarded? After all, if there is an open document that has never been saved and I try to close it, I'm asked if I want to save or delete it. Why would the last changes not be autosaved when I gracefully quit the app? It seems weird that changes are saved periodically, but not at the very end of the lifetime of the app. If I'm really supposed to autosave all documents manually in applicationShouldTerminate, which API should I call? Again, it seems weird that this is taken care of automatically until before quitting the app, and then I have to manually track which documents are saved and when everything's saved, quit the app. It would seem to me like boilerplate code that every document-based app would automatically want.

[quote='853904022, DTS Engineer, /thread/777545?answerId=853904022#853904022'] Your code has me a bit confused. [/quote] I should have gone more into details. The property in objectValue.observe(\.property) is actually an array of objects that represent a file URL, and in the observer callback I iterate through that array, create an image view for each element, and bind the image to a property of the respective element. The table view cell effectively displays a dynamic set of URL icons. I modify MyObject.property (I should have called it MyObject.entities) whenever an element is added or removed, and I modify MyEntity.image whenever the image changes. objectValue is set by the table view. I'll think if I can avoid using KVO, but this means I'll have to reload the table view cells manually in quite some places.

When any image view is being destroyed, make sure you're setting the target image to null and you've torn down any KVO "infrastructure" you've created that's tied to that object The NSImageView is in fact in a NSTableView, and I call NSImageView.bind(_:to:withKeyPath:options:) in the callback passed to NSObject.observe(_:options:changeHandler). The observer is added when the table cell view's objectValue is set, then removed again when it is set to nil. I'll add a call to NSImageView.unbind(.value) and see if that solves the crash. class MyCellView: NSTableCellView { private var observer: NSKeyValueObservation? override var objectValue: Any? { didSet { if let objectValue = objectValue as? MyObject { observer = objectValue.observe(\.property) { [weak self] _, _ in for view in subviews { view.removeFromSuperview() } let imageView = NSImageView(image: nil) imageView.bind(.value, to: objectValue, withKeyPath: keyPath) addSubview(imageView) } } else { observer = nil } } } } That's generally a reasonable statement for the "core" of Objective-C’s memory management model Not sure if it's relevant, but I'm using Swift, although I suspect KVO is at the Objective C level. I would also try Zombies Sorry, forgot to add that I also enabled that one, but no crash for now. I'll keep that enabled too. Thanks for your precious input and I'll update you when I find out more.

[quote='853647022, kthchew, /thread/795994?answerId=853647022#853647022, /profile/kthchew'] Also, not sure if the original poster's app is sandboxed, but if your app is sandboxed then it looks like the situation is potentially worse: [/quote] My app is sandboxed, and I'm not sure if I ever saw the wording you encountered. But that it indeed worse. In either case, the default action is to move the file to the bin. You're absolutely right (and I failed to point out) that these alerts make the user think that something's wrong or suspicious with the app, and possibly uninstall it. Personally, since the file can be opened once with "File > Open With", I don't see a reason why opening it permanently with "File > Open With > Other" would need such a scary alert.

Ah, I confused the macOS names. Can you show the code with your override and custom drawing?

they actually CREATE crashes Thanks, that's what I should have known but didn't fully realize until now. I just tried enabling the Address and Thread Sanitizer (the Main Thread Checker is already enabled), but couldn't reproduce the crash. I'll keep them enabled in the hope that they will create a crash at some point. whatever is going on doesn't involve some simple code flow I could understand that this crash could be caused by multiple threads releasing the image at the same time, but if only the main thread is accessing them, I cannot imagine how they could be over-released. I'm not doing any manual memory management with them or their parent object. If you have any example of how over-releasing could happen without thread contention and manual memory management, I'd be eager to hear it. Otherwise I'll let you know as soon as I'm able to reproduce the crash.

[quote='853568022, gnuoyd, /thread/779461?answerId=853568022#853568022, /profile/gnuoyd'] My custom cursor replaces the AppKit default cursor in every instance on Ventura. [/quote] Previously you said that it didn't work consistently. So does it work now? Since you're using TextKit 1 (by explicitly accessing layoutManager), that's expected: I managed to make it work with TextKit 1 as well, but was asking about TextKit 2, where it doesn't work.