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

[bugzilla-daemon at webkit.org]

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





------- Comment #99 from soto at informatik.uni-kl.de  2008-12-01 04:58 PDT -------
(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] patch?

All patches are available from this page, you should be able to do this
yourself in a minute. Am I missing something here?

>  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, so that we can start
contributing smaller patches.

>  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, pointing to a
private structure, pointing to a C++ object that finally pointed to the core
object. If more data has to be stored, it can be stored in the private
structure, just like the classes in GtkWebKit do. The structures are available
now and have a sane, consistent naming convention. We can use them if
necessary.

>  then we pick a better one.

This is already done, and, as far as I can tell, is consistent with other
classes in WebKitGtk.

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

[...]
>  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; 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,
and, for this reason, we should make sure that the GDOM classes follow the same
conventions, whenever possible.

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

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


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