Wolfire Games Forums

Hey Guys, great work.

You're blog posts have turned my team onto Awesomium. We were hoping you might spend a little time talk about what you've done, either on the blog or here.

In particular, I wonder three things:
* How did you work around the silly ClientObject for your Javascript binding? When playing with the Overgrowth alpha's, I notice none of your commands are preceded with "Client.", and I don't see any .js files providing that redirection. We are very interested in providing the same clean interface to our private APIs. If you made changes to Awesomium to achieve this, can you post the new code? (LGPL, baby!)
* Secondly, what hooks did you need to add to support the WebKit Console? Going through the WebKit code, that wasn't very obvious, other than finding the .html & .js sources and a couple of WebDevTool* classes. Any details would be greatly appreciated.
* Finally, assuming you're using multiple WebViews, are you sharing data between them? But this, I mean some variables in each context can refer to the same data. Without exposing the CppVariant or NPVariant, I don't see how to do this. Maybe that is exactly what your doing, which is what we're looking at, and would help resolve the first question above.

PS - If we come up with a clean solution to the above problems, I plan to send a patch to the Sirikata guys maintaining an LGPL branch. http://github.com/pathorn/awesomium

* How did you work around the silly ClientObject for your Javascript binding? When playing with the Overgrowth alpha's, I notice none of your commands are preceded with "Client.", and I don't see any .js files providing that redirection. We are very interested in providing the same clean interface to our private APIs. If you made changes to Awesomium to achieve this, can you post the new code? (LGPL, baby!)

We do actually use the ClientObject. Every command that communicates with the Phoenix Engine uses Client.something

AJS actually hooked us up with Awesomium himself, so I'm not sure if he made any changes. I think it's just the standard Awesomium, though.

* Secondly, what hooks did you need to add to support the WebKit Console? Going through the WebKit code, that wasn't very obvious, other than finding the .html & .js sources and a couple of WebDevTool* classes. Any details would be greatly appreciated.

I don't think we have any console specific hooks. I had to rip out 95% of the WebKit console JavaScript because most of it applies to DOM manipulation and other stuff, but the rest of it is just nude WebKit code, slightly modified so it still runs properly.

* Finally, assuming you're using multiple WebViews, are you sharing data between them? But this, I mean some variables in each context can refer to the same data. Without exposing the CppVariant or NPVariant, I don't see how to do this. Maybe that is exactly what your doing, which is what we're looking at, and would help resolve the first question above.

Hmm, I think AJS would have to answer this, that's beyond my level of abstraction. If I understand what you're asking correctly, then we do not do anything like that -- everything is abstracted through functions. We don't modify variables directly.

Jeff wrote:We do actually use the ClientObject. Every command that communicates with the Phoenix Engine uses Client.something

While there is plenty of use of Client.* code, I'm also seeing Camera.setFOV(..) instead of Client.setCameraFOV(), Graphics.setFullscreen(..) instead of Client.setFullscreen(..), and Engine.loadLevel(..) instead of Client.loadLevel(..). Additonally, I don't see any wrapper definitions in the Data directory. How do these get defined?

Ah, there is some wrapper code that is eval'd into the JavaScript context. For instance, Camera.allowCollision is actually function (){ Client.__ConsoleFunc_Camera_allowCollision.apply(Client, arguments); }

Jeff wrote:Ah, there is some wrapper code that is eval'd into the JavaScript context. For instance, Camera.allowCollision is actually function (){ Client.__ConsoleFunc_Camera_allowCollision.apply(Client, arguments); }

Hmm... Got it. And had I done Camera.allowCollision.toString(), I would have seen that.

Are you guys happy with (or at least comfortable with) the JSValue limitations? I.e. only strings and scalars passed into and out of the script engine.

Ahh.. what timing...
http://princeofcode.com/blog/?p=285