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

Sun Jul 26 13:24:56 PDT 2009

Let me put it even more strongly.

Luke, you need to stop sending long, rambling emails to the list. Many  
people have complained about both the form and content of your  
messages, and no one but you has spoken up that they find these emails  
useful. If you don't have the judgment to determine what messages are  
relevant to others, or how to make them concise enough to be readable,  
then your posting privileges will be suspended. WebKit is open to the  
public, but that doesn't give you the right to harass our contributors.

Regards,
Maciej

On Jul 26, 2009, at 1:52 PM, David Levin wrote:

> 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
>
> _______________________________________________
> 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/758d657e/attachment.html>