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

Wed Feb 11 06:06:18 PST 2009

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

------- Comment #135 from soto at informatik.uni-kl.de  2009-02-11 06:06 PDT -------
(In reply to comment #128)
>...
> My colleague Jim and I are highly interested in seeing DOM bindings added to
> WebKit/GTK.  Over the last couple of weeks, we've extensively cleaned up and
> enhanced the last patch posted here (posted by Martin Soto in comment #96 on
> 11/30) in an effort to resolve all outstanding issues.  Here is a list of the
> major changes we've made, followed by a list of potentially open questions.

First of all, I'd like to thank you for taking over. I'm writing my PhD thesis
right now and simply haven't found the time to keep this work going. By the
way, I must have a few things at home that I didn't manage to publish so far.
If I find something interesting, I'll make it available here later today or
tomorrow, just in case there are some bits and pieces you can use. Of course,
also, it would be nice to get this patch integrated, so that we can easily
contribute smaller patches

Some additional (random) comments:

> - In the last patch, each wrapper GObject pointed to a private structure which
> in turn pointed to a native C++ WebKit object.  (Comments on this thread show
> that there was previously yet one more level of indirection which Martin has
> already removed.)  These pointers were duplicated at each level of the
> inheritance hierarchy.  For example, a GdomHTMLButtonElement pointed to a
> native HTMLButtonElement, but the parent class GdomHTMLElement and all other
> parent classes also contained pointers to the native object.  This was
> unnecessary and wasteful.

I also wanted to remove this level of indirection but didn't know if it was
necessary for some reason (ABI stability?). Indeed, virtual machines and
interpreters (Python comes to mind) often add a level of indirection of their
own, so being as lean as possible on the GObject side is always a plus.

> ...
>  We doubt that will be necessary, but if we do need a private structure
> at some point we can simply update the void * to point to it without breaking
> binary compatibility with applications that use DOM objects.

Sounds great.

> GObject wrapper is initialized and call deref() when it's finalized.  As some
> reviewers pointed out, the existing code called ref() on some smart pointers in
> some cases, which was unnecessary; we've eliminated that wherever it happened
> in the code.

I did this same change in my (unpublished) code and it worked in all of my
tests. I went as far as loading arbitrary pages from the Internet and then
traversing their DOM using Python, so it seemed to be quite robust.

> ...
> With our changes, each DOM attribute is exposed both as a property and via
> getter/setter methods.  When the DOM specifies that getting or setting the
> attribute may raise an exception, the corresponding getter/setter method takes
> a GError ** for error reporting.  We're not particularly attached to using
> GObject properties at all, and can remove them if you like; that would
> significantly reduce code size (especially in the generated code).  It's up to
> you.

When are properties actually useful? They are unconfortable to use even in
Python. For widgets, software such as Glade benefits from them, but they don´t
seem to be so useful in the DOM. I wouldn't regret it if they dissapeared.

> - The last patch contained some support for reporting DOM events to the GObject
> caller.  The event interface was different from that specified by the DOM and
> the implementation was incomplete (there was no way to unregister an event
> listener).  In our patch we've removed all the event code, simply because
> events raise various design issues and we'd prefer to deal with them in a
> subsequent iteration.  As various commenters have mentioned, the patch is large
> enough as it is and removing the event code seemed like a good way to reduce
> its size.

This is a good idea for the moment. Events are very important, but we need to
get them right. Dedicating an iteration to them seems like the way to go.

> [Many clean-up actions described]

While we're on it, I noticed that the original patch uses the WebKit namespace
in some cases and the WebCore namespace in some other cases. Shouldn't this be
unified as well?

> - Where possible, we've renamed source and header files to have all-lowercase
> names as is conventional in GTK.  The autogenerated wrapper files still have
> CamelCase names because we use implicit makefile rules to generate these from
> .idl files, which also have CamelCase names, and GNU make doesn't allow us to
> perform a lowercasing transformation inside the implicit the rule.  So the
> autogenerated filenames don't quite fit the GTK convention; we don't think this
> is a significant problem.

Yes, I also ran into this problem. I don't think it is really bad if the
generated files use camel case, and it simplifies quite a few things. 

> == open questions ==
> 
> Here are design decisions that potentially remain open along with their current
> status.  We're happy to change any of these in the code to satisfy the
> consensus of the WebKit team.
> 
> 1. How should GObject DOM classes be named?
> ...

I would be for putting everything under the WebKit GObject "namespace". This is
not just some DOM, it's the WebKit DOM, and its classes are in the WebCore C++
namespace together with the rest of WebKit. This way, WebKitElement should do,
as it's guaranteed not to conflict with anything wrapped out of the WebCore
namespace.

That's it. Once again, I'm glad that you guys stepped in. I'm also looking
forward to seeing this patch integrated!

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