---------- Forwarded message ---------- From: Luke Kenneth Casson Leighton <l...@lkcl.net> Date: Jul 12, 2009 9:49 PM Subject: updated glib/gobject bindings patch To: webkit-dev@lists.webkit.org
this is worthwhile sending to the webkit-dev list, as i know that there are people following along. https://bugs.webkit.org/attachment.cgi?id=32633&action=review for those people who would like to skip the "patch webkit" step, feel free to use http://github.com/lkcl/webkit/16401.master instead, you'll find it's a lot easier. for those people who may not be aware: the glib/gobject bindings patch is a significant strategic addition to webkit for the free software community. in combination for example with pywebkitgtk's #13 patch, it puts webkit on a par with python-xpcom + python-hulahop and _finally_ brings webkit up on a part with pykhtml [KHTML has had python bindings to its DOM for .. years]. also, as you can see (read further below), vala bindings have also been created for webkit. macosx users have had numerous dynamic language bindings to webkit for several years - except.... GNU/Darwin hasn't been keeping up-to-date with cocoa and other Objective-C frameworks, meaning that it's only macosx users that can take advantage of the incredible flexibility offered. free software platforms are excluded. which is why these glib/gobject bindings are so strategically important. as a consequence, it's important i believe to get them right, and to get them to put webkit on a par with its peers from a free software perspective, which are: * MSHTML (the engine behind IE) * XULRunner (the engine behind firefox) * KHTML (the engine behind KDE's Konqueror) * Opera (except that's proprietary and i can't find the language bindings) it's significant to note that of the available browser engines, 2/5 are proprietary, and 1/5 is only DOM level 2 compliant. so - with those insights in mind, here is what i posted on the patch, and i trust that people will be interested to move this strategically important issue forward. l. ------------ okaay, this is the "2 steps backwards, 1 step forwards" patch which, as explained, cannot take into consideration adam's fantastic work because it was impossible for me to follow it. even _one_ feature removed (and the first that adam picked was event handling) meant that the test framework (pyjamas desktop) was totally cut off at the knees. dave agrees - https://bugs.webkit.org/show_bug.cgi?id=16401#c214 - that the way forward is to take this "as-is" and then to move forward from there. over what is likely to be a period of several months, retro-fix issues that have been raised and recorded will - should - be created. it would have been nice if people had listened to my advice on this months ago, but, not believing me, you had to find out for yourselves [by taking up adam's time as well as mine]. at least we're moving forward, now, rather than playing silly buggers. i'll be _more_ than happy to help review individual small dedicated controlled manageable single-purpose patches that anyone cares to contribute: perhaps by comparing the differences between what adam has done and what this patch provides it may make individuals' lives easier when it comes to updating this strategically critical area of functionality. there is a _lot_ still left to be done - but, butbutbut, what is here is _provably_ working. it would be very nice if it stayed that way, and that pyjamas-desktop, the only current project which utilised these bindings with near 100% code coverage, carried on working. still on the critical TODO list, after this patch is accepted (let alone any bug-fixes / coding-standards / review update work!) is: Enums, SVG 2D Canvas, and Exception handling. this latter is proving tiresome to not have, in pywebkitgtk (and pyjamas-desktop): several bugs could not be found in pyjamas-desktop until python-xpcom / XULRunner was added as an alternative back-end peer [to pywebkitgtk]. up until then, due to the lack of error reporting from runtime exceptions, style attributes and a few others just... silently vanished (fortunately with no useability impact, but that was down to luck). as requested, i've made review comments to https://bugs.webkit.org/show_bug.cgi?id=16401#c191 and https://bugs.webkit.org/show_bug.cgi?id=16401#c194 - the coding-standards issues i immediately fixed (as they're dead-easy) however there were issues raised that should have been raised eight months ago, when i had a complete map of the code and a handle on the 600+ auto-generated files in my head. i've answered them as best i can: now it's time to move on. one thing that can be seen from this patch: it includes LANGUAGE_GOBJECT as a #define. this is in for two separate reasons: 1) until someone can show me how to get a TextDocument object, in order to pass it to XMLHttpRequest.open(), for that reason and for that sole reason alone, LANGUAGE_GOBJECT is _absolutely_ required, in order to reactivate open(DOMString). otherwise, it's simply not possible to get XMLHttpRequest to work, and XMLHttpRequest working is a critical requirement of pyjamas-desktop [what's the point of having python bindings that are identical and a peer with the javascript ones if AJAX is bloody well missing???! :) ] 2) removal of LANGUAGE_GOBJECT was requested several months ago because it introduced features which are present in the de-facto Javascript standard (i.e. anyone coming from javascript would not be in for some unpleasant surprises) and it was stated that these features are not present in the W3C standard. after some extensive research, it was demonstrated that this wasn't quite true: the W3C standard makes specific mention that certain browser engines _do_ support the features. in fact, the research showed that by not having these features (i.e. by conforming strictly to the W3C standards), webkit would in fact be the _only_ major web engine that would not be on a par with its peers! even MSHTML has better support, because thanks to DCOM which has LP_VARIANT (which can take int, string, or in fact anything) and thus, unlike any of the other DOM implementations, the MS implementation of the DOM functions can support _both_ the W3C standard _and_ the de-facto javascript-led standard. regarding 2), i have put considerable thought to the matter and have some insights to share. from the perspective of the objective-c bindiings, strict W3C DOM standards compliance may make perfect sense. objective-c is a _compiler_. the auto-generated webkit objective-c header files are utilised at _compile_ time by the compiler to perform type-checking that can result in developers catching errors immediately. and, in objective-c, developers can take advantage of c++ classes that will be compiled, again at _compile_ time, into type-converters that will take strings as input, and convert to integers, and much much more. however - the glib/gobject bindings will - and are - be utilised by INTERPRETED languages. there is a WHOPPING great world of difference. there are two such (auto-generated) language bindings already (vala and python), and there will be more. vala - https://bugs.webkit.org/attachment.cgi?id=27558 python - http://code.google.com/p/pywebkitgtk/issues/detail?id=13 in the python case, the (currently sole and exclusive) project which is using pywebkitgtk with the DOM bindings is pyjamas - a python-to-javascript compiler. in other words, the only test case - the only really big significant (free software) test platform for the webkit glib bindings has a javascript-only cousin. that means that any applications written for pyjamas-desktop (which uses either pywebkitgtk or XULrunner python-xpcom) can also run as javascript, in all major web browsers. _that_ means that application developers may be developing exclusively in javascript, using the pyjamas python-to-javascript compiler. then, they encounter a requirement to have the application run as a stand-alone desktop app. then they download pywebkitgtk.... ... and they get a nasty big shock because the bloody underlying API is subtly different. without LANGUAGE_GOBJECT, all toString() functions would be missing; there would be no way to get the range of selected text out of input nodes; embed nodes would suddenly lose their width and height settings; XMLHttpRequest would be completely broken, and a few other nasty surprises. not one of these things is acceptable. the workarounds aren't particularly nice, either, and - again, the workarounds would be _great_ if these were COMPILED languages, with virtual base class function pointers etc. - but they're not: they're INTERPRETED languages, just like javascript. which reminds me of the other reason why many of the JS-isms should be enabled (such as getBoxObjectFor). again: in COMPILED languages, which are damn fast, calling functions like getBoxObjectFor via two or three levels of indirection makes absolutely no sense: just grab the attributes (width, height, top, left) individually and directly and write your own version of getBoxObjectFor which will, thanks to being a compiled language, be far far quicker. NOT so, in interpreted languages such as python. why? well, have you ever looked at python's Objects/abstractobject.c source code? it makes for interesting reading. and that's where all object access starts out. every single add, multiply, etc. goes through potential coercion checking. a single optimisation is made to check whether the two types are "int", and this is the _only_ case which is made faster: everything else goes through the "approx one hundred lines of c-code" route. just to do an add, or a multiply. so the very reasons for which the javascript-isms were created are just as equally valid for other dynamic languages as they are for javascript. overall then, for many many reasons, there is an overall compelling case to be made for sticking to the de-facto javascript standards over the W3C standards, for the glib/gobject bindings, and as equally a compelling case to be made for sticking to the W3C standards for the objective-C bindings. the two should not be confused, and developers using interpreted languages should not be put to incredible inconvenience (as well as the developers of the intermediate bindings) just for the sake of it. l. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
