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.leigh...@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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev