What I’m thinking about is what if all of my code could be used as a webkit 
extension, i.e. I could make the class definitions conform and create idl files 
for each of my class, and stick them all in a new directory under 
WebCore/Modules. Looks like then, I would have to modify a single CMake file 
(CMake is cool, I’ve been using CMake for over a decade :) )

One thing that’s not entirely clear to me is how exactly is JSC made aware of 
the all of the generated class bindings. The internals of each of the binding 
files is very clear: a series of accessor methods, and references to all these 
are made in a JSC::ClassInfo struct. I see a createPrototype static method in 
each class, but I can’t seem to find out how these get called. 

I’d like to be able to create native windows (either NSWindow on OS X, or 
native W64 via CreateWindow on Windows), and I’d like to create a set of C++ 
objects with appropriate JavaScript bindings that currently executing 
JavaScript can create and interact with. Its trivial for me to create JSC 
bindings, the bit that I’m not sure about is should these live in the host 
application side, or in the new modules I’d create under WebCore/Modules. 

I’m looking closer at the internal of JavaScriptcore, and remember, I’m working 
on a new programming language. It looks like it would be straightforward to 
compile it to the JavaSciriptCore binary object layout. This would create a 
bridge where all of the new object could interact directly with existing JS 
objects. 




> On Jun 1, 2016, at 4:09 PM, Myles C. Maxfield <mmaxfi...@apple.com> wrote:
> 
> From the description, it sounds like you have some native code which needs to 
> be able to modify the DOM and you need events from the DOM to be able to call 
> code from your library. You can do this today without modifying WebKit.
> 
> The way for native code to modify the DOM is for the native code to generate 
> a JavaScript string and submit the string to be run inside the JavaScript 
> context of the page. You can do this in WK1 by JSEvaluateScript(), the 
> WebScriptObject, or by stringByEvaluatingJavaScriptFromString. In WebKit2, 
> WKWebView has a method evaluateJavaScript (Or from C you can run 
> WKPageRunJavaScriptInMainFrame, but this isn’t considered API)
> 
> You can also use Objective-C DOM bindings to manipulate the DOM directly from 
> native code, this approach is discouraged.
> 
> One way for DOM events to call code from your library is to create a 
> JavaScript object or method which is backed by native code. Then, the 
> JavaScript event handler can call the functions on this object, which causes 
> your native code to run. This can be done with the functions listed inside 
> Source/JavaScriptCore/API/JSObjectRef.h.
> 
> In WebKit2, this native-backed-object can still be made, but it must be done 
> inside the Web process (not the UI process), and therefore must be done with 
> the InjectedBundle. Inside the InjectedBundle, you can run native code in the 
> web process, and there are facilities to send messages between the Web 
> process & UI process. You can find out more if you search for 
> “InjectedBundle” inside Source/WebKit2/UIProcess/API. Note, however, that use 
> of the InjectedBundle is not considered API.
> 
> We rely on the above mechanisms heavily in our testing infrastructure. Our 
> Tools/DumpRenderTree and Tools/WebKitTestRunner projects use the techniques 
> described above.
> 
> The Windows port currently doesn’t support WebKit2, so you’ll have to use the 
> WebKit1 approach on Windows.
> 
> 
>> On Jun 1, 2016, at 11:49 AM, Andy Somogyi <somog...@umail.iu.edu 
>> <mailto:somog...@umail.iu.edu>> wrote:
>> 
>> 
>>> On Jun 1, 2016, at 1:37 PM, Myles C. Maxfield <mmaxfi...@apple.com 
>>> <mailto:mmaxfi...@apple.com>> wrote:
>>> 
>>> Replies inline.
>> 
>>> Generating a DOM is usually done in JavaScript. I'm curious about the 
>>> problem you are trying to solve where JavaScript is not sufficient.
>>> 
>>> Drawing into an existing window is usually done by inserting a WebView into 
>>> the view 
>>> reallyhierarchy of the window. Yet again, I'm interested in why this is not 
>>> sufficient.
>> 
>> I have the source code of the new language, and a parser/compiler for it 
>> written in C++. I’d hate to have to introduce a new set of languages into 
>> the mix. 
>> 
>> The new programming language is designed to be visually edited, hence the 
>> need for hit detection. So, a component may be dragged from one region to 
>> another. This would trigger an event which would cause one branch of the AST 
>> to be pruned, modified and re-attached to another branch. This in turn would 
>> trigger a re-gen of the render tree, and eventually a repaint. I've done 
>> something very similar in the past where I created a visual computer algebra 
>> system. The entire runtime, including AST are written in C++, and it would 
>> be nice to connect it to an existing rendering/layout engine, and be able to 
>> respond to user events directly in my C++ code. 
>> 
>> I see this as a very dynamic application, and all of the internal logic 
>> which is a mix of C and JIT compiled code from the new language needs to 
>> interact with both the visual representation, and the physics engine (the 
>> Lang is designed for real-time physics simulation). Ideally, I'd like to be 
>> able to render a visual representation of a language element to an OpenGL 
>> texture, and have this exist in the physics engine. 
>> 
>> However, being as the DOM is publicly available from WebKit in C++ (I think 
>> they’re all exposed publicly as pure virtual interfaces), it would be 
>> relatively straightforward for me to to compile the new language to target 
>> the C++ v-table ABI. 
>> 
>> 
>>>> Do you think this would be possible using WebCore as a library and have 
>>>> these custom render tree / dom tree derived objects live in my own library 
>>>> (this is really, really the way I’d prefer to do things), or do you think 
>>>> it would be better to add these objects directly into the WebCore library. 
>>>> 
>>> 
>>> Are you planning on committing any changes to trunk?
>>> 
>>> Of course it is ::possible:: to do something like this - it's all software. 
>>> Are you asking if it's easy to do it? Or the best way to do it
>> 
>> On OSX, I don’t think I’ll have to do any changes at all to WebKit. I’ve got 
>> proof of concept working where I create a new RenderElement derived object, 
>> and give it a new GraphicsContext. 
>> 
>> However, on Windows, the classes I use from WebKit in my own code would need 
>> to be exported via the WEBCORE_EXPORT macro, this would need to be added to 
>> each class definition in WebKit. I suppose what I could do is write a quick 
>> script which adds this macro to each class that I use as part of my build 
>> process. That way, I would not have to touch the upstream webkit source at 
>> all. 
>> 
> 

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to