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. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
