Joshua.Shagam at am.sony.com
Tue Apr 27 16:06:33 PDT 2010
Okay, that's what I was afraid of. For now I think I'll just write
bindings against libxml, then. Thanks.
Eric Seidel wrote:
> Various WebKit ports expose different bindings. The JS bindings are
> only exposed to scripts on pages run inside WebKit.
> to set up your own custom bindings for that environment. We don't
> really provide clean APIs for that, however, there has been talk over
> the years of taking the bindings/scripts and making it possible for
> clients of WebKit to generate JSC-API compatible autogenerated
> bindings wrapping their own implementation objects.
> You'd still have to write your own implementation objects which talked
> to the right pieces of WebKit/WebCore however.
> I think you'll run into a world of pain if you try and just expose
> guts of WebCore to clients outside of WebCore w/o having gone through
> the normal WebCore parsing mechanisms and created a Page, Frame,
> Client objects, etc.
> Anyway, best of luck and we look forward to seeing your contributions.
> On Tue, Apr 27, 2010 at 3:56 PM, Josh Shagam <Joshua.Shagam at am.sony.com> wrote:
>> Thanks. I apologize for mincing terminology - I'm not particularly versed
>> etc., and I've mostly been banging my head against this based on looking at
>> work that some of my coworkers have done. :)
>> I should be more specific that we are in fact linking against WebKit and so
>> we will have the implementations available. We are actually using full
>> WebKit for another part of the system as well, but we'd like to be able to
>> access WebKit's JS bindings from outside of the WebKit view.
>> It looks like bindings/scripts bit will help me get on the right track, in
>> any case. Thanks for the pointer.
>> Eric Seidel wrote:
>> DerivedSources are generated from here:
>> I think what your'e thinking of as DerivedSources is actually just the
>> implementations in WebCore.
>> If for some reason you wanted to write your own custom bindings which
>> use JSC's public API instead of the internal one which WebCore uses,
>> you could make your own generator script:
>> You can see examples of those scripts being run in DerivedSources.make
>> or in run-bindings-tests:
>> In short, this is not a supported configuration. :) I'm also not
>> really sure it's on topic for this list.
>> Best of luck!
>> On Tue, Apr 27, 2010 at 3:44 PM, Josh Shagam <Joshua.Shagam at am.sony.com>
>> scripting engine outside of WebKit. It would be very helpful to us if we
>> could get access to the DOMParser and XMLSerializer classes which are in
>> WebKit's DerivedSources area. However, it seems that those libraries are
>> etc.) rather than the public interface expected by external users of
>> We'd also like to avoid pulling in the internal WebKit headers anyway, as
>> this would complicate our build system (for example, we'd like to be able to
>> do this just using the header files provided by Ubuntu's libwebkit-dev
>> package). I'm fine with writing forward-declaration classes and stub
>> methods for the purpose of letting the C++ linker figure it all out, but
>> JSC::JSValue seems to get in the way of this idea, since the
>> getConstructor() methods on the libraries we want return it by value rather
>> than by reference (and it doesn't appear to be a simple reinterpret_cast
>> like it is for the other public-API classes).
>> Is there some official way that we can get at WebKit's DerivedSources
>> anyone think of some tricky-but-relatively-clean way to do it that doesn't
>> involve our app having to see JSC's internal API?
>> Thanks in advance.
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev