[webkit-dev] DOMRange and khtml::Selection direction

[Duncan Wilcox]

> 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