[webkit-dev] adding gtk/gobject DOM bindings to webkit - code review and advice needed

Luke Kenneth Casson Leighton lkcl at lkcl.net
Fri Aug 22 07:04:44 PDT 2008

hi folks,

(message goes out primarily webkit-dev but also gtk-devel-list because
 someone there might be able to give some hints on the gobject code-generation
 being developed.)


embarrassingly, after actually trying to use the - successful - 
event manipulation and javscript-snippeting i added, i found that i was
considering techniques so damn awful, to be able to exchange variables
between the python and the javascript that i couldn't bring myself to do it
ha ha.

so.... i decided to have a go at the CodeGenerationGObject.pm that alp
kindly posted at https://bugs.webkit.org/show_bug.cgi?id=16401
this is what i have - and what it generates - so far (and i will
update it as i make progress):


i won't say that i know what i'm doing, but i know the end-result - sort-of -
so i will meander towards the solution (as usual. eventually).

to speed that random hit-and-miss process, a review and some pointers
would be greatly appreciated.

what, ultimately, should the code look like?

is the "private" classing i'm using appropriate?
should i be placing a pointer-to-the-object-being-wrapped as the
"gobject private class" instead of creating an (otherwise pointless
because i believe it should only contain one member - {Classname}* )
GDOM{Classname}Private struct?

can i pretty much copy the "creation" style of the "JS" code generation?
example: for the createElement function in DerivedSources/JSDocument.cpp
do i just... i assume i do pretty much the same thing.

if so, where do i get an ExecState from? _do_ i need one?  (i suspect
not but confirmation greatly appreciated).

this is horrendous but fascinating in that... horrified "i can't quite
believe how much is going on" kind of way.  it's really addictive :)


p.s. whoever chose perl as the code generator i will strangle them happily
if ever i meet them, and will sleep happier at night, knowing that there is
one less perl advocate on the planet. once the job's done, of course,
because i might need their advice :)

More information about the webkit-dev mailing list