Hello!
In our codebase we have a NSView
subclass that conforms to NSTextInputClient
. This protocol is currently not marked as a main actor, but in the decade this has been in use here it has always been called on the main thread from AppKit.
With Swift 6 (or complete concurrency checking in Swift 5) this conformance causes issues since NSView
is a main actor but not this protocol. I've tried a few of the usual fixes (MainActor.assumeIsolated
or prefixing the protocol conformance with @preconcurrency
) but they were not able to resolve all warnings.
So I dug in the AppKit headers and found that NSTextInputClient
is usually implemented by the view itself, but that that is not a hard requirement (see NSTextInputContext.h the documentation for the client property or here). With that I turned my NSView
subclass extension into a separate class that is not a main actor and in my NSView
subclass create an instance of it and NSTextInputContext
. This all seems to work fine in my initial tests, the delegate methods are called. But when the window loses and then regains key, I see a warning message in the console output.
-[TUINSCursorUIController activate:]: Foo.TextInputClient isn't subclass of NSView.
So my question is, am I doing it wrong with the custom class that implements the protocol? Or is the warning wrong?
I would also appreciate a hint on how to better resolve the concurrency issues with NSTextInputClient
. Is a main actor annotation coming at some point from your end?
Thanks!
Markus