We keep the modification minimal on both Node and Chromium. Only 2 things are done: main loop integration and context bridging.
Chromium have their main loops. So it would take some efforts to make it run in
Chromium. One of the founding feature of node-webkit is to call Node functions directly from DOM, so we integrate them into the same thread. That requires the integration of the main loop of Node and the one from Chromium Render process.
In order to make the objects from Node and DOM to refer to each other, Node is made to use the same V8 engine instance as the one in Chromium. The objects from the 2 worlds are in 2
contexts respectively, to keep their namespace clean.
Chromium internally use class
MessagePump to support its events loop, since
libuv to support its events loop, we need to implement a new
MessagePump which uses
libuv as its underlying events library. The new type of Message Pump is used only in the render process, where the WebKit engine resides.
base/message_loop.h to understand our work.
On Mac things are a lot different, see
This is the most important and trickiest part of
node-webkit, first we initialize a context for
node, and make
node setup all its stuff under it, see
content/renderer/renderer_main.cc, then when WebKit has installed DOM into its context, we move everything from
third_party/WebKit/Source/WebCore/bindings/v8/V8DOMWindowShell.cpp in line 346.
node has a
Start function that setups everything, it will redirect everything into its own message loop, so we split the
Start function into several parts, see
node itself expects to execute a script file, there are many logics that deal with script execution in
third_party/node/src/node.js, we heavily modified that part and used some tricks to make its module system run under
Another modification resided under
third_party/WebKit/Source/WebCore/bindings/v8/V8DOMWindowShell.cpp in line 363, we inserted some script after WebKit is initialized, so
node can get a right
filename which is vital to