Between NSResponder overrides and NSTextInputClient conformance, WKView has almost everything needed to control text editing. I would find the following additional methods particularly useful: - (void)setSelectedRange:(NSRange)charRange Can be simulated by using moveLeft:/moveRight: and moveLeft/RightAndModifySelection: but that is painful and slow. - (void)centerSelectionInVisibleArea:(id)sender Helpful complement to setSelectedRange:, so the user can see what's going on. - (NSInteger)length In Carbon's IMKInputSession protocol but not NSTextInputClient. Can be simulated by moveToEndOfDocument: followed by selectedRange, but that modifies the selection. Supply either this or - (NSAttributedString *)attributedString If I can get the whole string, I can get its length. But once I have its length, I can use attributedSubstringForProposedRange:actualRange: - (void)replaceCharactersInRange:(NSRange)aRange withAttributedString:(NSAttributedString *)attributedString Can be simulated with setMarkedText:selectedRange:replacementRange: followed by unmarkText, though I wonder about potential unwanted side effects. The use for these is to implement a scripting extension allowing an editable WKView to be synchronized with and corrected by an external grammatical correction app. This works very nicely in classic WebKit, but WebKit 2 doesn't expose enough Objective-C methods or other hooks. Accessibility interfaces might be an alternative way of achieving this, but impose a very different view of the editable document.
> If I can get the whole string, I can get its length. But once I have its length, I can use attributedSubstringForProposedRange:actualRange: You should be able to use that with a range that's larger than the whole document - it's just a bug that WebKit2 doesn't update the range to what it actually produces.
Please note that the WKView interface is not stable and no one should be relying on it exposing anything at this point. Longer term, I think we would like to get off of NSTextInputClient as it imposed a synchronous API on us, something we really don't like.
(In reply to comment #1) > > If I can get the whole string, I can get its length. But once I have its length, I can use attributedSubstringForProposedRange:actualRange: > > You should be able to use that with a range that's larger than the whole document - it's just a bug that WebKit2 doesn't update the range to what it actually produces. Fixing that would indeed be the best solution (and was the first thing I tried out, but my hopes were dashed after seeing the current implementation).
(In reply to comment #2) > Please note that the WKView interface is not stable and no one should be relying on it exposing anything at this point. Longer term, I think we would like to get off of NSTextInputClient as it imposed a synchronous API on us, something we really don't like. I have no attachment to NSTextInputClient (beyond the fact that it codifies one way of doing much of what I want, though not all). In the absence of a dependable, complete interface, I take what I can get, tread very lightly, expect frequent change and degrade gracefully. That having been said, it would be really nice not to have to resort to skullduggery to accomplish what I'm trying to do. Old WebKit didn't publish quite enough, so I still had to rely on private methods. The last time there was a semi-standard (scripting) interface for these tasks was in the days of the AppleScript Word Services suite... Apart from the methods I mentioned in the original report, the only other one I need is - (NSRange)selectedRange Allows me to handle only part of the text, if the user makes a selection before requesting correction (sort of like the way Mail will use just the selection for the quoted text in an email reply). So basically, all I want to be able to do is get and set the selected range, get and set text within a range (including the whole document), and scroll to keep the selection visible. I also need a reliable way to determine if the current selection is editable or not: no point trying to work with static text.
Can you tell us more about the bigger picture? The last time I dealt with scripting additions was many years ago, and now I'm surprised how you are even able to load any code inside Safari (I assume it's Safari that is hosting WKView in question, correct?) If what you really need is a new feature in Safari built-in scripting dictionary, please file a bug via <http://bugreport.apple.com>.
The bigger picture is text correction in a separate writers' tools app, with its own UI (as opposed to an NSSpellServer which depends on the standard UI). Users request correction through the Services menu. Once the request has been received, we synchronize changes in both directions between the original app and the correction app, until the correction app's shadow document is closed. Additional features in Safari's scripting dictionary (yes, Safari is the WKView host) would certainly be one way of continuing to offer this integration. Scripting does suffice in the cases where it is well supported (Microsoft Word, Adobe InDesign, etc.). Because scripting dictionaries of Cocoa apps are rarely rich enough, a scripting addition that targets NSTextView has been a successful technique for a wide variety of apps. Extending the idea to the old WebView allowed working with Mail and Safari (until now). WKView is not so amenable. I'll file a bug on bugreport.apple.com with a reference to this bug.
rdar://9544103