smb big sur

@Mr. Jefferson , did this ever get solved for you? Did you find your own solution or find one elsewhere? @Frameworks Engineer, do you have a follow-up to OP's reply to your comment? I ask because I'm having the exact same issue. I'm coding a word processing app with custom behavior that requires running checks before deleting, and then changing attributes around/near the deletion point after deleting. (I have some other custom behaviors that are affected by this same issue but for simplicity will just refer to the deletion one.) I want to be able to use default NSTextView behaviors that already come with free undo/redo (e.g., typing, deleteBackward(:), insertNewline(:), but then want to modify attributes for a certain range of the textStorage afterward. I register my attribute modifications with the undoManager. Like OP, I can get undo/redo to work flawlessly but only when using only NSTextView default behavior OR when using only my modifications/undos to the NSTextStorage. The second I start mixing both,

I have built over hundreds of websites using Flutter Web in the last 4 years. Now, I am in big trouble.

Hi @DTS Engineer, Thank you for your assistance and support. Regarding the issue of a file being exclusively locked by Quick Look Extension Preview, I believe this might be an oversight. Here are some points to consider: Prior to macOS 15, the Quick Look Generator Preview functioned without this issue. However, the Quick Look Extension Preview exhibits this problem. In the Quick Look Extension system, thumbnail generation works without issue, but preview generation does not. As Alberto pointed out, text previews are unaffected, whereas image previews are impacted. Quick Look does not seem to require an exclusive lock on a file for reading purposes. Given these observations, it seems likely that the exclusive lock behavior in the Quick Look Extension Preview, when accessing files over SMB, in unintentional. If this is not an oversight, could you kindly explain why an exclusive lock is necessary in the Quick Look Extension Preview? This insight would help us better understand the situation and explore

its hard to find the emoji I need because they’re too big, and it’s making my texting language weird now because I can’t find the one I need. It’s too many pages to scroll through. My eye sight is medically normal. 20/20. can we please go back to normal size? 🙏

Sorry about the delay responding; I’m juggling too many cases right now. I’m going to start with the big picture: [quote='813576022, harshal_goyal, /thread/766557?answerId=813576022#813576022, /profile/harshal_goyal'] While we are exploring mDNS-based discovery using Bonjour, our primary goal is to create cross-platform applications … [/quote] Support for the Bonjour protocols [1] are either built-in or readily installable on all major platforms. [quote='813576022, harshal_goyal, /thread/766557?answerId=813576022#813576022, /profile/harshal_goyal'] we are focused on process discovery—identifying processes running on the same network, regardless of whether they expose a service. [/quote] OK. But that doesn’t preclude the use of Bonjour, you just need to think of each process as a service. [quote='813576022, harshal_goyal, /thread/766557?answerId=813576022#813576022, /profile/harshal_goyal'] We are avoiding the use of multicast DNS (mDNS) because it adds overhead and costs. [/quote] What sort of overhe

The most disturbing emoji new look! U can not choose from the small banner down specially the recent, then emojis are too big so it takes ages to scroll between pages to find the right emoji… please need a solution to this asap 😭😭😭😭 just bring the emoji display as it was

It’s hard to answer this without a lot more details. In general, macOS and the notary service continue to tighten up their checking of code in order to close security holes. Some of those are big changes, when we tend to announce widely. I have a bunch of links to such things in Trusted Execution Resources and the other Resources posts that it links to. But some of them are relatively minor changes that don’t get widely advertised. And some changes are just implementation changes that happen to cause problems for code that’s not following the rules [1]. [quote='770552021, hamish258, /thread/770552, /profile/hamish258'] DMGs built, signed and notarised successfully are now failing codesign verification. [/quote] If you run syspolicy_check against such an app, what does it report? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Historically those rules were very poorly documented. That’s much better these days, but lots of code, a

I agree with Ed, that the “Leaks” instrument is not as illuminating as the “Allocation” instrument. The “Leaks” instrument is most useful (in those edge-cases) where you are writing code that does manual alloc/free or retain/release. If not, it is generally identifying (usually very small) issues largely outside of your control. But if you don’t have your own code that is doing alloc/free or retain/release, the “Leaks” instrument is not terribly illuminating. Your “Debug Memory Graph” diagnostics, though, are very effective in identifying strong reference cycles. But rather than focusing on the bottom of the tree (the fact that the NSSet was used deeply within Foundation types), I would focus on the top of that tree. E.g., it looks like the NSSet was created by some AVFoundation layer view. So, I would focus on the AVFoundation usage within the app. Even better, in the left panel of the “Debug Memory Graph”, I would advise that we focus on our own objects, i.e., those objects over which we have control. To th