[Webkit-unassigned] [Bug 16401] [GTK] GObject/C DOM binding

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Sep 13 08:36:58 PDT 2008


------- Comment #30 from lkcl at lkcl.net  2008-09-13 08:36 PDT -------
alp, hi, great!  thanks for the comments - much appreciated.  lots to be
getting on with :)

ok - first things: little bit of explanation.

the Private*, PrivateInt* and Gdom*props.h headers were created to avoid major,
major headaches in the generation and use of #includes.  a number of times i
ended up with circular #include dependencies, and the only way to break them
was to split the header files.

one of the key purposes of splitting the headers is to keep the internal class
implementations separate from their use (e.g. in webkitwebview.cpp).  so,
although things are declared as a typedef GdomDOMdocuement for example, they're
never actually dereferenced - hence the Private header files contain the actual
structs. i also liked the idea of keeping the stuff that was stored _in_ the
Gobject separate as well (the classes that all derive down to GdomDOMObject) -
hence the private cpp file.

but... yes... you're right: it's a superfluous requirement - more of a style
thing.  but the header files: absolutely not.  it was hell getting those right

regarding the trailing white space: yep, more than likely.  many of the
hand-edited files started life off as auto-generated and modified or borrowed

regarding the strings thing: yep :)  i just... guessed at the best function,
relied on the compiler to tell me where i was going wrong.  if there'd been any
comments in the code "don't use this, use this" i'd have gone "oh, look, i'm
supposed to use this" ... :)

decamelise: yehh, i just cut/paste your original work, alp :)  i fell afoul of
the h2defs.py codegen for pywebkitgtk, too, over the x_path_blah things.  urgh.

GStringConvert originally began life as a macro, and, after running into KURL
and other strings, quickly turned into a class.  not having created _any_ files
in WebCore/bindings/gdom at the time, i avoided it.... that's my excuse :)

the string GC thing sounds... _really_ messy.  samba avoids the issue entirely
by having talloc - a system of memory allocation which remains
permanent-per-context.  when you destroy the group of objects with which the
talloc context is associated, you know it's safe to destroy the talloc context. 

apache has something similar, with "pools".

in both cases, the only "free()ing" you do is at the global level, when you
free the entire talloc (or the entire pool).

the only reason i returned the strings at all as g_alloc()ed was because i
anticipated that there might be conventions for dealing with strings in
glib/gobjects - "caller frees return results".

[certainly in DCE/RPC applications, which is the mother-of-all RPC systems, the
convention is "caller frees return results".  it _has_ to be that way, because
of the client-server divide.  then if you remove the RPC middle layer, and link
the client-bit-of-code to the server-bit-of-code in one monolithic app, the
application still behaves correctly, memory-wise.]

in python - specifically the codegen stuff - the .defs file can specify "caller
owns result" - something like that - or "callee owns result = false". 
indicating that code must be auto-generated to free up the return result when
it's no longer needed.

now, if there's a safe way to return a pointer to e.g. the underlying unicode
string, rather than make a copy of it as utf-8, then heck, i'll do that!  glib
does support unicode strings (er... he said...)

pffh, i've no idea what i'm talking about - i'm neither a webkit not a glib
expert :)

the separate library-space thing i _really_ like - for exactly the reasons you
say: namely that the gdom bindings really don't have anything to do with gtk. 
which is great.

to make it abundantly clear, i'd love to see pywebkitqt make use of the glib
bindings (yes i'm serious!)  i've been toying with the idea of _not_ adding to
pywebkitgtk but instead creating pywebkitgdom.  aside from anything,
pywebkitgtk  is really small, and it's a bit cheeky to turn it from a 50k to a
300k monster!

so, a pywebkitqt4 could easily import pywebkitgdom.  the interface between the
two would be a bit iffy, though, even if it was in only two or three places
(like it is in webkitwebview.cpp) hmmm...

more later.

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the webkit-unassigned mailing list