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
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
