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

Tue Dec 2 01:47:38 PST 2008

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

------- Comment #103 from lkcl at lkcl.net  2008-12-02 01:47 PDT -------
(In reply to comment #99)
> (In reply to comment #97)
> >  great!  can i ask you a favour?  could you produce a diff of the diff?
> >  i.e. using the original patch as the baseline, prepare a patch with changes
> >  from the original patch into the attachment 25618 [review] [review] patch?
> 
> All patches are available from this page, you should be able to do this
> yourself in a minute. Am I missing something here?

 yes: 1) lack of disk space 2) the inconvenience 3) we're working from
different
 reference points.

> >  alternatively, martin, would you like to collaborate on this via a shared
> >  revision control system?
> > 
> >  i believe i've mentioned that i'm using github.org
> 
> I would be, yes. Never used git, but I guess I can quickly learn the basics.
> Still, it'd be better to get this landed in some form,

 ahh... slight fly in the ointment, there: "in some form" must still be
 "useful".  as in, it must still actually do the job it's intended.

 at _no time_ can "in some form" _not_ provide the full functionality
 and satisfy all of the requirements that the code currently meets.

 which is why, mark, i did not provide a "dumbed-down" version.
 [i expect you, as a paid employee of apple, to be able to get
 the time to follow].

> so that we can start contributing smaller patches.

 xxxxing tell me about it.

> >  mmm... i made them that way to follow along with the conventions advised
> >  by various documentation and howtos that i trustingly read, but also because
> >  if there is anything _else_ that needs to be stored in the private gobject
> >  structure, the wrapper is needed.
> > 
> >  for example, at some point, the exception handling is going to be added back
> >  in (see functions in JS wrappers, they take _two_ arguments: c++ webkit obj
> >  and an exception object), and it will _not_ be added to the webkit webcore
> >  c++ objects: the only place therefore available to store and retrieve it is:
> 
> That's just fine. The private structures can remain if they are needed, that's
> why I asked before removing them.

> But we had a public structure,

 a c interface where the headers are transparent.

> pointing to a
> private structure,

 the glib interface struct where the c++ object is presently stored,
 and in the future, the exception object will also be stored.

> pointing to a C++ object

 that's an absolutely necessary wrapper object that contains the
 pure virtual function getGObjType(), and is tied in to the
 DOM Object cache in GDOMBinding.cpp

 without that pure virtual function, the whole system collapses as
 you cannot correctly typecast an object back to its proper c++
 core object.

 i've explained this a number of times, but to reiterate: the issue
 that's faced is illustrated by the following pseudo-code:

 n = doc.createElement("div")
 n.id = "testid"
 body = doc.getElementsByTagName("body")[0]
 body.appendChild(n)

 not_same_n_but_it_should_be = doc.getElementByid("testid")

 assert(not_same_n_but_it_should_be == n) /* ERROR THROWN! */

 the reason why this would fail - if you removed that
 "pointing to a c++ object" is because doc.getElementById()
 returns Node*.

 so, if you naively return a Node*, then a *separate* Gobject
 is returned - which, underneath, points to the same core c++
 object (typecast down to a Node*)...

 ... you see where this is going?

 so, when the createElement() function was called, an HTMLDivElement
 was created, and a Gobject of type GDOM_TYPE_HTML_DIV_ELEMENT was
 created.

 this goes into the GDOMBinding DOMObject cache.

> that finally pointed to the core object.

 i purely and simply followed, verbatim, the examples shown in the
 tutorials found online, and followed what was _necessary_ to provide
 the required functionality.

 correctly.

 so - sorry, but it has to stay as-is.

 this wouldn't have ended up being coded as it is without a
 damn good reason.

> >  the glib / gobject patch has nothing to do with and has zero dependency on
> >  WebkitGtk.
> 
> Of course, this code doesn't depend on WebKitGtk. Still, it has a lot to do
> with it.

 this may come as a surprise, but it has very little to do with WebKitGtk.

 the entry-points - the links between webkit-gdom and webkit-gtk is 
 currently about four or five functions, and it _should_ be only one
 or two.

> In particular, being also GObject based, it should follow the same or
> very similar coding conventions. I see no reason to depart from coding
> conventions that are already established and known to work.

 acknowledged.

> [...]
> >  ok - two things to emphasise: first, this is a good idea, second, this patch
> >  has _nothing_ to do with WebKitGtk's functionality.
> > 
> >  this patch is a _gobject_ patch that _happens_ to be utilised, in the first
> >  instance, by WebKitGtk as the first port.
> > 
> >  other ports - the qt and the wxWidgets - are perfectly at liberty to utilise
> >  the webkit-gobject bindings, by #including <glib.h>
> > 
> >  they DO NOT i repeat DO NOT have to #include <gtk.h>.
> 
> This is all absolutely clear to me, although I'm not so sure that the Qt or
> WxWidgets port would like to use this;

 yehh... they might not - but the alternative is to go through seven kinds
 of hell adding yet _another_ set of bindings, bringing the total to five
 if QObject is used and... what does wxWidgets have - that'd be six.

> maybe the Clutter port, which is also
> GObject based. I agree with you that we don't want the DOM classes to depend on
> WebKitGtk. But we do want WebKitGtk to depend on the DOM classes in some way,

 yes.

 the dependency can be reduced to about two functions and two glib-based
 objects.

 a glib wrapper around a pointer to the virtual base class WebCore::Page
 (let's call it WebkitWebPage)

 and another one around WebCore::Frame (which already exists in gdom);
 WebkitWebFrame should have a pointer to a GdomFrame, and should take in
 a pointer to a WebkitWebPage as well.

 in this way, it's possible for other ports - qt and wxwidgets - to
 create their own WebkitWebPage and their own GdomFrame, set up the
 links between the two, and you're done.

 it's not "QObject-y".  it's not "wxWidget-y".  but it works, and those
 ports could then replace the functionality, at their leisure, with
 QObject-y DOM bindings and wxWidget-y DOM bindings.

> and, for this reason, we should make sure that the GDOM classes follow the same
> conventions, whenever possible.

 yes.

 ... what are they?

> > > This is no problem, but I'm wondering about the GDOM prefix.
> > 
> >  yeah, i don't like it, either.
> > 
> > > I see no reason to have a different prefix for
> > > the DOM related objects. They belong to WebKitGTK 
> > 
> >  no, they don't.  that's why alp suggested that the functionality go into
> >  its own library - libwebkitglib.la - to strongly emphasise this.
> 
> OK, let me correct my assertion: both WebKitGtk and the GObject DOM classes are
> GObject-based bindings for WebKit functionallity. And they are closely related,
> since the GDOM classes will be used to manipulate a DOM that will often be
> displayed through a WebKitGtk widget.

 i should reiterate: the sole link is via one function.  once you have a
 pointer to what is now called "GdomDocument", WebkitGtk's role is OVER.

 finished.

 oh.  other than event handling.

 so, there's an event link (i gave it a signal name of "browser-event")
 and there's a way to get a GdomDocument.

 NOTHING else.

 sure, things like window.open() might get called, and things like
 window.alert(), or other such interaction...

 but it's NOT "triggered" by gtk, or by any gtk interaction, and not by
 any gtk functions, and not by any WebkitGtk functionality.

 gtk's role is _extremely_ limited to some _very_ specific roles that have,
 other than the passing in and out of a pointer to a Frame, a Page, a
 Document and some event handling, absolutely nothing to do with the
 webkit-glib DOM bindings.

> > > as much as anything else,
> > > and, in my opinion, should use the same naming convention. Would people agree
> > > with this? Should I just change everything to use the WebKit (or webkit_
> > > dpending on the case) prefix?
> > 
> >  yep, i agree.
> > 
> >  _despite_ the fact that the naming convention is identical to that chosen
> >  by webkit's gtk port.
> > 
> >  it would be much better for the webkit gtk port to take a prefix of
> >  "WebkitGtk", and for the webkit-glib code to take a prefix of "Webkit".
> 
> Well, I don't know to what extent it is necessary or useful to make this
> differenciation. I see the need for separate libraries, because other
> GObject-based ports, such as the Clutter port, may want to depend on the DOM
> classes but not on WebKitGtk.  If we want all names to reflect this, I don't
> know, Actually, the WebKit (or webkit_) prefix refers to WebKit as a whole.

 yes, and as such, webkit/gtk is causing inconvenience, having "taken over"
 that namespace.  pywebkitgtk does the same thing - it's called itself
 "webkit" not "webkitgtk" or "gtk.webkit".

> given that both WebKitGTk and the DOM classes are wrapping WebKit
> functionality, I don't see a problem if they use the same GObject namespace.

 ack.

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