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

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=16401





------- Comment #35 from lkcl at lkcl.net  2008-09-14 05:45 PDT -------
> _init functions vs. constructors:
> There are some generated functions like gdom_wheel_event_init_wheel_event().
> These should probably be mapped to GObject constructors, ie.
> gdom_wheel_event_new().

i no unnerstaan.

ok - explanation time.

the way that the code is set up, there is no way for external code
(users of the library) to call gdom_xxxxxx_xxxx_new().  none.  not
a single one. this is thoroughly deliberate. the only entry point is
through webkitweb*.cpp.  yes, i realise this will have to change
(in order to support webkit-glib as an "independent" library).

... quick hunt through source code to find if i end up making a
GdomFrame... no.  huh.  ok...

i think... the sensible thing to do would be to create a manual
GdomFrame, which _does_ have a gdom_frame_new() constructor etc.
which takes in the Frame, etc.  looking closely, it'd be virtually
identical to webkitwebframe.cpp - except with no mention of
"Gtk" anywhere.

anyway.

there's zero public access to the gdom_xxx_new() functions.
not even webkitwebframe.cpp or webkitwebview.cpp or even
the new event handling webkitwebevent.cpp call them: they
all use "toGDOM()" which is the equivalent of "toJS".

in fact, now i remember: i *entirely* removed the gdom_xxxx_new()
functions.  the *only* place where gdom gobjects get created is
in WebCore/bindings/gdom/GDOMBinding.cpp create_gdom_object().

note the use of the virtual function, GDOMObject::get_gobj_type()

the only way to get the that create_gdom_object() function is
via a toGDOM() function - of which there are... 300 or so, 297
of which are auto-generated.  create_gdom_object is even _static_
to GDOMBinding.cpp.

in this way, it's absolutely cast-iron guaranteed that the glib
objects will be "managed" (by the hash-map); that a c++ object which
has already had a glib wrapper created around it gets the same
glib object back, even if a glib object of a different type (base
class) is being requested; that all the ref()s are handled correctly.

if i were to let people do gdom_xxx_new() calling, those guarantees
would no longer be in place.

additionally, once you have that initial "Frame", there's no _need_
to go calling any gdom_xxx_new() functions, because of all the
getter functions and the creater functions - and the constructors
in the DOM model and the IDL files.

so, the glib bindings would do well to have a manually-coded GdomFrame,
which WebKitWebView either derives from or has as a member, thus making
it even clearer that the glib gdom bindings are independent of gtk; providing
that single-entry choke point into the gdom functions n stuff.

so - although it would be a good idea to map
gdom_wheel_event_init_wheel_event to gdom_wheel_event_new() - there
doesn't actually exist a gdom_wheel_event_new() to map _to_ :)

... not that i entirely understand what you mean by "map", so i apologise
if this explanation is particularly long and pointless, but i hope it
helps at least explain some of the very-quickly-made design decisions.


-- 
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.