On Aug 12, 2005, at 3:35 PM, Duncan Wilcox wrote:
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?
We can probably get away with that, but adding something to a header
would be a no-no.
Does the Apple API review have to be done on an actually integrated
patch?
Sorry, I don't understand the question.
API review has to happen before a copy of Mac OS X can go out with
the new API in it. We don't want any API changes checked into the
tree in a public way that are not yet approved because it would
prevent us from submitting the TOT into a Mac OS X build. But we can
put them in "staging" places to get ready. The approval doesn't take
long.
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?
Maybe. My thinking on this isn't very clear.
khtml::Selection doesn't implement but does have affinity for start/
end/base/extent, so perhaps affinity is meaningful also for ranges?
Good point. I don't know.
-- Darin
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
