[Webkit-unassigned] [Bug 61889] Please expose additional editing APIs in WKView

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=61889





--- Comment #4 from Justin Bur <justin at cam.org>  2011-06-02 11:27:29 PST ---
(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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.