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

Duncan Wilcox duncan at mclink.it
Fri Aug 12 10:17:32 PDT 2005

> 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 {
} 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;


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) 

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.


More information about the webkit-dev mailing list