[webkit-dev] Fwd: updated glib/gobject bindings patch
Luke Kenneth Casson Leighton
luke.leighton at googlemail.com
Sun Jul 12 21:35:33 PDT 2009
---------- Forwarded message ----------
From: Luke Kenneth Casson Leighton <lkcl at lkcl.net>
Date: Jul 12, 2009 9:49 PM
Subject: updated glib/gobject bindings patch
To: webkit-dev at lists.webkit.org
this is worthwhile sending to the webkit-dev list, as i know that
there are people following along.
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
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.
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
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
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#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
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
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
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
in other words, the only test case - the only really big significant
(free software) test platform for the webkit glib bindings has a
that means that any applications written for pyjamas-desktop (which
uses either pywebkitgtk or XULrunner python-xpcom) can also run as
_that_ means that application developers may be developing exclusively
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
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.
just as equally valid for other dynamic languages as they are for
overall then, for many many reasons, there is an overall compelling
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
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.
More information about the webkit-dev