Re: Online Desktop and GNOME 2.22

[Alp Toker <alp atoker com>]

John Stowers wrote:
> For example, the new shiny HTML5 client db stuff in webkit [2] will go 
> some way to allowing desktop apps to be written in HTML/JS and then 
> run inside a light webkit shell, but can we do better. What about
> * A simple way to start a webkit browser widget associated with a 
> private, standalone httpserver? - might be necessary if someone wants 
> to write apps in PHP/some other server side language

Hey John!

Your ideas are on the right track but we do it a little differently in 
WebKit, mostly to the same effect.

Our strategy with WebKit is to discourage traditional gtkmozembed hacks 
like embedding a web server in the process, in favour of providing 
direct access to the resource request/response layer and Document Object 
Model via GObject. Of course, you can still ship a web server with your 
product as a migration path if you want to deploy PHP applications.

One of the entry points you might use to access the DOM, just to give 
you an idea of what I mean here:

DOMCSSStyleDeclaration* webkit_page_get_style (WebKitPage *page);

> * Some way to communicate gtk-isms/function calls from the html/js app 
> to the desktop. For example, I have previoulsy acomplished this (in 
> pygtkmozembed) by
> 1) encoding  gtk function calls as javascript status messages
> 2) catching on_status_changed and then reecreating the call
> Can webkit facilitate some sort of Gtk/GNOME javascript binding?

We're just about to enable a complete C API to access the JavaScript 
engine, allowing calls into JS as well as the creation of completely new 
dynamic JS objects complete with custom callback handlers, which can be 
accessed directly from WebKitFrame, for example:

JSGlobalContextRef webkit_frame_get_global_context (WebKitFrame *frame);

I've created a proof of concept JavaScript D-Bus bridge using only this 
new C API so it's already quite powerful and expressive.

I hope that WebKit will encourage application developers to actually 
move away from some of the practices you describe and back towards real 
GTK+ applications that use Web technologies as a complement, not a 
replacement, for our existing platform.