[webkit-dev] status update: webkit gobject bindings [svn r46395]

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.

dave

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
> http://github.org/lkcl/webkit/16401.master.
>
> 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:
> https://bugs.webkit.org/show_bug.cgi?id=27435#c10
> https://bugs.webkit.org/show_bug.cgi?id=27435#c13
> 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
> bindings.
>
> 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:
>  http://code.google.com/p/pywebkitgtk/issues/detail?id=13
> * 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:
>    [gui]
>    #engine=hulahop
>    engine=pywebkitgtk
>  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
> maintaining.
>
> * 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.
>
> l.
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090726/828c50a9/attachment.html>