I saw this on python-announce, and all I can say is "What the heck?" I think this means you can write a Python application and have it compile down to an Ajax application or a desktop application, but I could be wrong:
webkit-glib-gtk provides gobject bindings to webkit's DOM model. pywebkitgtk provides python bindings to the gobject bindings of webkit's DOM model.
files are available for download at: https://sourceforge.net/project/showfiles.php?group_id=236659&package_id=290457&release_id=650548
separate pre-built .debs for AMD64 and i386 Debian are included, for pywebkitgtk and webkit-gtk with gobject bindings to the DOM model. if you have seen OLPC/SUGAR's "hulahop", or if you have used Gecko / XUL DOM bindings, or KDE's KHTMLPart DOM bindings, you will appreciate the value of webkit-glib-gtk. pywebkitgtk with glib/gobject bindings basically brings pywebkitgtk on a par with hulahop.
code-stability-wise, pywebkitgtk and webkit-glib-gtk should be considered "experimental" (not least because this is a release from a svn build!). that having been said, pyjamas-desktop is declared "production" because pywebkitgtk with DOM bindings, thanks to webkit-glib-gtk, provides absolutely everything that pyjamas-desktop needs (and if webkit-glib-gtk becomes a moving target, the DOM.py abstraction layer in pyjamas-desktop will take care of it. if it becomes a _severe_ moving target, pyjamas-desktop will drop webkit and provide a python-hulahop / XUL-Geck port instead. or as well. whatevrrrr :).
gobject-interface-wise, the webkit gobject DOM bindings that have been added _can_ be considered to be "stable", as long as the underlying webkit library IDL files are "stable" (additions to Console.idl were made in the past couple of months, for example, and HTML5 is making advances as well). that having been said, _some_ functionality proved intransigent during the initial main development phase of the webkit gobject DOM bindings, such as RGBColour conversion of CSS Style Properties, and so were *temporarily* left out. given that pyjamas-desktop is considered "production", that should give a pretty clear indication of the importance of those rare bits of DOM model bindings features that were left out. SVG Canvas bindings, however, have NOT been included, as that would have added a further 120 gobjects to the list.
instructions for anyone brave enough to install webkit-glib-gtk from source, themselves, on macosx: http://github.com/lkcl/webkit/wikis/installing-webkit-glib-on-macosx there is an (experimental) Portfile in the macosx 10.4 glib tarball, as well.
the actual differences, however, are extremely small, percentage-wise. out of around 300 objects, providing around 1,500 functions, and tens of thousands of properties, there are approximately 20 functions that are different, and only four properties that are different.
examples of the differences in the bindings APIs offered by ObjectiveC and webkit-glib-gtk Gobject bindings include:
* XMLHTTPRequest.send accepts a DOMString on the webkit-glib-gtk bindings, whereas what should actually be passed in is a Webkit Document object. various attempts were made to create appropriate TextDocument and XMLDocument objects: unfortunately they failed miserably. fortunately, earlier versions of Webkit provided a version of XMLHTTPRequest.send which accepts a DOMString argument, and this version was reactivated for the webkit-glib-gtk bindings. the ObjectiveC and all other bindings successfully pass in a Webkit Document object. this issue will at some point need to be addressed, however it's pretty low priority: using a DOMString works just as well.
anyone wishing to provide bindings to other languages, such as ruby, perl or java: the pygtk-codegen-2.0 application pretty much made mincemeat of webkit.defs (available on request, or look at code.google.com/p/pywebkitgtk issue #13 - i may update the patch soon enough) and absolutely _no_ funny business - overrides of _any_ kind - were required! the only "funny business" that's in pywebkitgtk overrides is to do with gtk, not the webkit gobject bindings. 300 objects, 1500 functions and tens of thousands of properties all get added with a vanilla .defs file. unbelievable. so this spells "good news" for the garbage-collecting languages (e.g. ruby, perl, possibly java): if your language-of-choice's gobject-auto-generator is as good as python-gobject's auto-generator, you should be up-and-running within literally a couple of hours. oh - but first: i would advise you to look at pywebkitgtk's "demobrowser.py" for guidance on how to create a webkit gtk app (using your language of choice) first, followed by looking at pyjamas-desktop's "pyjd.py" for further hints on how to bind to the DOM model functions [pyjd.py is based on demobrowser.py].
c++ is a different matter. webkitgtkmm will _not_ be gaining DOM bindings based on webkit.defs. after discussions with jonathon jongsma, we came to the conclusion that it would be far better to write a _separate_ set of bindings (gobjectmm) actually in webkit, due to subtle information being available that is lost by the time you get to webkit-gobject c-bindings. anyone anticipating to write or have webkitgtkmm "up-and-running", providing gtk / gobject bindings to webkit's DOM model, should expect to take between three and four weeks in writing a CodeGeneratorGobjectMM.pl, using the other WebKit CodeGenerators as guides.
that's all, for now. bugs should be reported to the respective bugtrackers of the appropriate projects - http://code.google.com/p/pyjamas, http://code.google.com/p/pywebkitgtk and http://bugs.webkit.org should do the trick.