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

[Luke Kenneth Casson Leighton]

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.