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

[Darin Adler]

On Aug 12, 2005, at 10:17 AM, Duncan Wilcox wrote:

>> 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

I don't think I'd use the word "View" in this name. And maybe not  
call it range either. Perhaps "selection" is a better name.

> The plan would also be to add new methods to WebView:
>
> - (void)setSelectedWebViewRange:(WebViewRange *)range;
> - (WebViewRange *)selectedWebViewRange;

Right. Modulo name changes.

> since WebView also has a standalone - (NSSelectionAffinity) 
> selectionAffinity perhaps a - (WebViewSelectionDirection) 
> selectionDirection is needed for symmetry?

Nah, no need. The affinity methods are the same as ones in  
NSTextView; I don't think we need the full set.

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

Right, that's one great thing about how informal delegate work.

> 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.

I'd like to look at all methods with DOMRange parameters and consider  
this.

> If this sounds good perhaps you can give me some advice on names  
> and I can proceed with a bug+patch.

This is a nice basic approach.

Since this is the first time we've done a patch that introduces new  
public WebKit API there is at least one thing to consider. New API  
needs to be staged so it can go through the Apple API review process.  
This means that at first we'd put the new API into a "planned to be  
public API" place that's not in a public header, and then move it to  
the public header after the API review is complete. That's just  
because the Safari team might need to "submit" this to an OS X build,  
and we can't change public API there until it's approved.

I wonder if there's anything else that this selection object might  
need to include.

Another thought, maybe only single caret selections need the concept  
of affinity and only range selections need direction, so there may be  
something we can do to take advantage of that.

     -- Darin