User Profile

The Drawing fully immersive content using Metal guide describes how to use Metal for visionOS immersive experiences, but seemingly requires swift to bring up the required CompositorLayer. @main struct MyApp: App { var body: some Scene { ImmersiveSpace(id: "MyContent") { CompositorLayer { layerRenderer in let renderThread = Thread { let engine = myEngineCreate(layerRenderer) myEngineRenderLoop(engine) } renderThread.name = "Render Thread" renderThread.start() } } } The ImmersiveSpace scene can presumably be replaced with a call to [UIApplication.sharedApplication activateSceneSessionForRequest:[UISceneSessionActivationRequest requestWithRole:UISceneSessionRoleImmersiveSpaceApplication] errorHandler:nil] But is there a replacement for CompositorLayer? Or some other way to produce a cp_layer_renderer? Perhaps it would be possible to write a small swift helper for this, but given the swift interface for CompositorLayer how would that be tied to an existing UIScene as created above? @available(visionOS 1.0, *) public struct CompositorLayer : SwiftUI.ImmersiveSpaceContent { public init(configuration: any _CompositorServices_SwiftUI.CompositorLayerConfiguration = .default, renderer: @escaping (CompositorServices.LayerRenderer) -> Swift.Void) public var body: Swift.Never { get } public typealias Body = Swift.Never }

The "Debug View Hierarchy" feature of Xcode is very convenient to break down and debug a complex view hierarchy. But Metal content/layers/views do not render anything in this mode. Is there some special flag that needs to be set on the layer to support the Xcode feature? Or some special callback that needs to be implemented? I would naively assume that Xcode could do some kind of read-back from the window server or GPU, even for layers rendered via accelerated APIs like Metal or OpenGL, similar to what's done when recording/capturing the screen. Filed as FB13509137

What's the right way to implement key equivalent matching that handles non-Roman/Latin layouts? E.g. pressing Cmd+Option+C in a Greek layout produces an NSEvent with chars="ç" unmodchars="ψ", neither of which is going to match a key equivalent of Cmd+Option+C by simile comparison, yet performKeyEquivalent on a button with that exact key equivalent returns YES and activates the button. How would someone replicate that? [NSEvent charactersByApplyingModifiers:] also reports "ç", and so does UCKeyTranslate. Yet the Keyboard Viewer shows a modifier layer with "c", not the "ç" that the event reports:

Based on these Swift docs and this forum thread, keyboard shortcuts / key equivalents are expected to be declared based on a US English layout. As an application developer, you may then rely on the auto localization provided by allowsAutomaticKeyEquivalentLocalization, (for menus) or localize your key equivalents manually (menus and other controls with key equivalents). But how does AppKit handle non localized key equivalents when faced with a non-US English keyboard layout? In particular, with a Hebrew layout active, the C key unmodified produces "ב", but when modified with ⌘ produces "c". Does AppKit compare the key equivalent ⌘c to the modified or un-modified char of the event, or both? Or is there more to this logic? E.g. does it also try to match the incoming event against a US-English layout, even if not active at the moment? The use-case here is implementing performKeyEquivalent for a custom control, where the documentation says: You should extract the characters for a key equivalent using the NSEvent method charactersIgnoringModifiers. So would simply comparing the event modifiers to the key equvialent modifers, and the event charactersIgnoringModifiers to the key equivalent give similar behavior to AppKit's own logic, e.g. in [NSEvent _matchesKeyEquivalent:modifierMask:]? Based on the observed behavior when pressing ⌘c with a Hebrew layout active, it does trigger an NSButton with a key equivalent of ⌘c, which doesn't seem to match the documented behavior of using the unmodified chars ("ב") as basis.