> On Jun 1, 2016, at 1:37 PM, Myles C. Maxfield <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 hierarchy 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 really 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
