Interestingly, [NSEvent _matchesKeyEquivalent:modifierMask:] returns YES for a real key event:
NSEvent: type=KeyDown loc=(21.2695,-129.457) time=78998.2 flags=0x100108 win=0x13227f2c0 winNum=2566 ctxt=0x0 chars="c" unmodchars="ב" repeat=0 keyCode=8
But NO for a synthesized event via [NSEvent keyEventWithType]
NSEvent: type=KeyDown loc=(0,0) time=0.0 flags=0x100000 win=0x0 winNum=0 ctxt=0x0 chars="c" unmodchars="ב" repeat=0 keyCode=8
torarnv
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
User for
From
Oslo, Norway
Post
Replies
Boosts
Views
Activity
The flags, location, time, window, and winNumber might affect this, or perhaps [NSEvent _matchesKeyEquivalent:modifierMask:] also looks at state outside of the arguments?
Please see additional replies below, thank you.
The reason for the synthetic event not behaving the same as the real key event was that the synthetic event didn't have an eventRef, causing _matchesKeyEquivalent to bail out early. Calling syntheticEvent.eventRef (https://developer.apple.com/documentation/appkit/nsevent/1525143-eventref?language=objc) forces NSEvent to lazily create the eventRef.
Nice, that helps to see the properties! Unfortunately we use a CAMetalLayer in an NSView, not MTKView, so we're not seeing those properties shown in the screenshot above. Is there a way to drill down in the inspector from a NSView to its layer?
Posted https://developer.apple.com/forums/thread/761001
tl;dr, golang doesn't produce LC_UUID, which is important for the network privacy subsystem
It's a reasonable bug, however, IMHO the "fix" here should be to reject the extension as invalid at load time. Executable need to include build UUIDs.
Agreed. A clear indication up front (UI or warning/error in system logs or as detailed in the returned error in the network API layer) that the executable can't even ask for network permissions would have helped diagnose this.
Agreed. A clear indication up front (UI or warning/error in system logs or as detailed in the returned error in the network API layer) that the executable can't even ask for network permissions would have helped diagnose this.
You can create NSAdaptiveImageGlyphs for the emoji keyboard by turning photos into "stickers". As far as I can tell this uses the same underlying APIs for text as Genmojis will when released.