[webkit-dev] status update: webkit gobject bindings [svn r46395]
levin at chromium.org
Sun Jul 26 12:52:26 PDT 2009
Maybe zecke's email wasn't clear. Here's another attempt:
"Brevity is the soul of wit" --William Shakespear
Verbosity hinders your goals.
On Sun, Jul 26, 2009 at 11:52 AM, Luke Kenneth Casson Leighton <
luke.leighton at googlemail.com> wrote:
> this is a progress report for archival and informational purposes on
> the upkeep of bug #16401, providing useable and useful glib / gobject
> bindings to the full webkit DOM implementation. pending inclusion in
> webkit svn, the code is being kept up-to-date on an ad-hoc basis at
> as the last 16401.master update (svn r44624 or so) was from a few
> months ago, yesterday was "update to svn r46395" day, which was
> uneventful except for two major things:
> * updating to latest svn forced the use of the latest (git) revision
> of libsoup, which in turn incorporated a critical bugfix.
> * since the last change, a new attribute concept has been added to
> webkit IDL files: [reflect] and [reflectURL]. an initial attempt to
> ignore any properties with such attributes was made, but that quickly
> turned webkit-gobject (and pywebkitgtk) into something completely
> unusable, and it had to be fixed immediately.
> in short, then, the latest svn update has been done successfully
> without loss of functionality to the bindings, and the python bindings
> (pywebkitgtk) which in turn depend on webkit glib/gobject bindings
> have also suffered no loss of functionality, either.
> regarding the #16401 patch work, david kiltzer made an excellent
> suggestion two weeks ago which paved the way to split the 6,000-line
> patch down into smaller patches. individual discussions can now take
> place and be easily tracked. it is anticipated that if a discussion
> shows signs of getting too complex, covering too many issues, that it
> be split into further separate bugreports.
> so far, there are fifteen separate patches (all linked as blocking
> #16401) with more expected. the "biggie" is CodeGeneratorGObject.pm:
> everything else is infrastructure. CodeGeneratorGObjectLibrary1.pm is
> the first split, and it is anticipated that this file be split further
> (on an arbitrary 50% basis unless someone voices a better suggestion
> which saves developer time and money).
> patches to "GNUmakefile.am"s have *not* yet been submitted. all
> patches but the one to WebKitWebFrame have *zero* impact on the normal
> compilation process of webkit, regardless of compile-time options.
> all of the remaining patches simply add code that will remain
> completely unused, until the GNUmakefile.ams and WebKitWebFrame are
> also patched.
> the addition of LANGUAGE_GOBJECT to the IDL files has thrown up some
> oddities, just in the review process, such as #27603. it turns out
> that the HTML5 spec has moved on, making certain exceptions in the IDL
> files unnecessary. this is very fortunate, because all the work put
> into the gobject bindings is made useless if there are features
> missing from them.
> in that regard, it may be of interest to note these curious questions:
> the summary of these questions, regarding provision of XMLHttpRequest
> via language bindings, is basically, "wtf??" :) and, as can be seen
> by the extensive but non-exhaustive replies, XMLHttpRequest via
> language bindings is a critical and integral part _of_ the language
> the summary lesson, shown by the only project currently and fully
> using the webkit gobject bindings (pyjamas desktop) is that it is
> absolutely absolutely necessary to have access to absolutely
> absolutely everything [in the DOM] - or you might as well not bother.
> at all. with respect to sam and alexey, the curious questions that
> you usefully raise highlight quite how much of a mismatch of
> understanding and appreciation for what is possible with web browser
> language bindings there still is, in the webkit community. [overall
> this leaves me somewhat flustered because i must be failing to
> communicate correctly just how powerful this stuff really is].
> also it's worth noting that pyjamas desktop provides an indirect route
> to comparing xulrunner language bindings against webkit language
> bindings (and the plan is to add MSHTML as well, using
> python-win32com). so far, the differences are trivial and small, with
> webkit being the 2nd class citizen with respect to its provision of
> access to the DOM. one of the reasons why i am fighting the reviewers
> so hard is to ensure that what is accepted into webkit svn does not
> result in the webkit gobject bindings falling behind its peer,
> python-xpcom and MSHTML. simple differences which can be trivially
> worked around are tolerable, but significant differences, such as
> missing out entire areas of functionality such as XMLHttpRequest or
> having properties which are strings in MSHTML, KHTML and python-xpcom
> but are integers in webkit really cannot be tolerated.
> if you are interested in seeing webkit obtain useful and useable free
> software language bindings, how can you help?
> * first, compile up the patched #16401.master version of webkit from github
> * second, compile up the patched version of pywebkitgtk:
> * third, install pyjamas (see http://pyjs.org).
> you will need to do this:
> python bootstrap.py
> sudo python run_bootstrap_first_then_setup.py install
> * fourth, get familiar with the pyjamas examples, running them
> using pywebkitgtk. to do this, create a file ~/.pyjd/pyjdrc
> with the following contents:
> then you can do this:
> cd examples/kitchensink
> python KitchenSink.py
> having seen what's possible, you're now in a position to appreciate
> just how powerful language bindings to web browser technology really
> are, and will have a better feel for the direction that #16401 is
> * fifth, go to https://bugs.webkit.org/show_bug.cgi?id=16401, ignore
> all 300 or so comments, and make yourself known.
> * sixth, take a look at the list of dependent bugs and pick one to
> help out with.
> there are a number of areas where work is needed: adam's work on the
> GNUmakefile.am auto-generation could well do with being incorporated;
> there are auto-generators needed, such as for gdom.h and for
> GDOMHTMLElementWrapperFactory. these are self-contained tasks that
> would be of enormous benefit and would generally make everyone's lives
> a lot easier.
> lastly, it has to be said: once #16401 is done, there are months of
> additional work to be done - several additional tasks, such as adding
> support for SVG 2D Canvas. #16401 is just the beginning.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev