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.
Would probing a delegate via respondsToSelector: for a not-yet-public delegate method be a problem or does it have to be disabled until the review is done?
Does the Apple API review have to be done on an actually integrated patch?
I wonder if there's anything else that this selection object might need to include.
Can't think of anything myself...
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.
You mean merging NSSelectionAffinity and WebSelectionDirection in some way?
khtml::Selection doesn't implement but does have affinity for start/ end/base/extent, so perhaps affinity is meaningful also for ranges?
Duncan _______________________________________________ webkit-dev mailing list [email protected] http://www.opendarwin.org/mailman/listinfo/webkit-dev
