Right, we'll need to either add an extra parameter or change the
class of the existing parameters.
Ok so the plan might be something like this:
typedef enum {
WebViewSelectionNoDirection,
WebViewSelectionForward,
WebViewSelectionBackward
} WebViewSelectionDirection;
@interface WebViewRange : NSObject
{
DOMRange *range;
NSAffinity affinity;
WebViewSelectionDirection direction;
}
- (DOMRange *)range;
- (void)setRange:(DOMRange *)newRange;
- (NSAffinity)affinity;
- (void)setAffinity:(NSAffinity)newAffinity;
- (WebViewSelectionDirection)direction;
- (void)setDirection:(WebViewSelectionDirection)newDirection;
@end
The plan would also be to add new methods to WebView:
- (void)setSelectedWebViewRange:(WebViewRange *)range;
- (WebViewRange *)selectedWebViewRange;
since WebView also has a standalone - (NSSelectionAffinity)
selectionAffinity perhaps a - (WebViewSelectionDirection)
selectionDirection is needed for symmetry?
Finally the WebViewEditingDelegate category would gain a new:
- (BOOL)webView:(WebView *)webView shouldChangeSelectedWebViewRange:
(WebViewRange *)currentRange toWebViewRange:(WebViewRange *)
proposedRange stillSelecting:(BOOL)flag;
while for compatibility the appropriate methods in WebHTMLView.m
should call the previous method if the new one isn't available:
- (BOOL)webView:(WebView *)webView shouldChangeSelectedDOMRange:
(DOMRange *)currentRange toDOMRange:(DOMRange *)proposedRange
affinity:(NSSelectionAffinity)selectionAffinity stillSelecting:(BOOL)
flag;
WebViewEditingDelegate has a few other methods that use DOMRange,
however at a quick look it doesn't seem that it's strictly needed, if
not for symmetry again.
If this sounds good perhaps you can give me some advice on names and
I can proceed with a bug+patch.
Thanks,
Duncan
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
