Anyway, thanks again for the quick response last time. I've considered that I'll probably look for other options.
- Tom On Sat, Aug 11, 2012 at 10:23 PM, Thomas Palmer <tjpal...@tjpalmer.com>wrote: > Thanks for the info. I had seen the goals page, but it's hard to know for > sure what's potentially in scope. DOM can be for more languages than JS, > but I'm okay with what the maintainers consider appropriate. > > I guess I'll look at source control history, see if I can take the churn > level, and find out what I can do on my own. > > One other thing. Is there a chance of being willing to simplify the > include dirs list by always consistently including from a few top-level > dirs? I might be willing to go to the pain myself of changing all the > include directives, but only if I knew y'all would consider accepting it > when I was done. > > Thanks, > Tom > > > On Sat, Aug 11, 2012 at 7:00 PM, Ryosuke Niwa <rn...@webkit.org> wrote: > >> On Sat, Aug 11, 2012 at 4:49 PM, Thomas Palmer <tjpal...@tjpalmer.com>wrote: >>> >>> This has probably been asked before, although I haven't used the right >>> search terms. >>> >>> I would __LOVE__ to use WebCore as a C++ library, and it has all these >>> wonderful things like WebGLRenderingContext and dom things and whatnot. I'd >>> have little need to use another UI toolkit in my life, so far as I'd be >>> concerned. But none of it is exported in the public WebKit interface, nor >>> is it available, for example, in the webkitgtk so file. >>> >>> I have seen the partial Chromium interface (having tried it first >>> through Chromium itself), and I see that WebKit2 is exposing a bit at least >>> in a C interface. Also, apparently the internal WebCore APIs are considered >>> unstable. Is all this correct? >>> >>> What is the game plan for the future on this front? >>> >> >> http://www.webkit.org/projects/goals.html >> WebKit is not a bundle of maximally general and reusable code. >> We build some general-purpose parts, but only to the degree needed to be >> a good web content engine. >> >> So if your plan is to re-use our code for other purposes, we're unlikely >> to accommodate that. >> >> If I went to the effort of trying putting exports on all the WebCore APIs >>> using a #define that is turned off by default, could that possibly be an >>> acceptable patch? How unstable is WebCore? I'm inclined to think I'd be >>> willing to ride with the flow if it's at least semi-stable, and I suspect >>> WebKit maintainers also feel little need to churn too much. >>> >> >> What are you referring to by WebCore APIs? We refactor and change class >> names, methods, etc... in WebCore all the time. WebKit API is there >> explicitly for this purpose so that we don't have to be constrained by >> external projects. >> >> - Ryosuke >> >> >
_______________________________________________ webkit-help mailing list webkit-help@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-help