On Thu, 2008-10-23 at 15:10 +0100, Daniel L. wrote:
Does this mean that WebKit bindings should provide
GtkMozEmbed bindings compatible API?
I don’t believe this to be the case, or desirable.
I’ve now used all of GtkHTML2, my embryonic bindings for GtkHTML3,
Ruby/MozEmbed and have been working on filling out the rest of the
capabilities in the Ruby/WebKit stuff that Dan started.
I was out most of the week, so I haven’t had a chance to do a lot with
the WebKit changes I made yet. I’m hoping to be able to do some work on
this over the weekend and let Dan see what I’ve done. There’s still
some tidying to do…
The WebKit bindings reflect the WebKit/GTK API. This API has been
influenced by the MozEmbed, GtkHTML and other projects, but it isn’t
exactly the same. In many ways, you can’t do interesting things with
MozEmbed until you get ahold of the XPCOM interface for the core
One of the advantages of WebKit over MozEmbed is that they’re making an
effort to expose more of this core functionality through a native GTK
API so that it is easier to embed and extend in GTK applications. While
it is mostly trivial to provide a basic adapter from WebKit to the
MozEmbed API, I don’t think that this belongs as part of the library.
Currently, I have a working BrowserView API that essentially allows me
to encapsulate embedding most of the 4 APIs mentioned above in a
transparent way to the rest of my application. While I think that
something like this has its uses, it solves a separate problem.
Anyway, we can’t add a new package into Ruby-GNOME2 project
I am happy to be the maintainer, although I’m not sure that the
WebkitGtk bindings to Webkit have themselves stabilized enough yet to
be relied upon yet. Andrew Townley has been doing some work on them
more recently than I have, so perhaps he can help us decide that with
more up-to-date information.
One of the things I haven’t had a chance to do is put the conditional
compilation flags in to allow Ruby/WebKit to support various
distributions’ packages of WebKit. The work I’m doing is based on
SVN/trunk, but that requires compiling all of WebKit from source. It is
far from complicated to do, but it does take some horsepower and time.
My impression is that unless you’re just doing basic loading of web
pages, there are some parts of the API that are missing. I’ve raised
these issues on the webkit-dev mailing list, and there are some open
bugs around some of this functionality. Various of the other ports have
implemented these things in slightly different ways, so it is hard to
say what direction WebKit/GTK will go.
If I have the time, I might try to fill in a couple of these gaps that I
need, but I’m quickly using up the time I’ve allocated to getting a
working application done. I still don’t have the application
functionality I need to have because I’ve been working on bringing in
the underlying library capabilities into Ruby.
I personally don’t think that Ruby/WebKit should be part of the
mainstream Ruby-GNOME2 distribution until the WebKit/GTK release has
stabilized. I’ve discussed with Dan how to integrate the changes to
track the functionality I need, but I think the right thing to do at the
moment is for Dan and myself to just maintain it separately. Once the
WebKit/GTK API is finished/stabilized, then I think it makes more sense
to bundle in with part of the Ruby-GNOME2 distribution.
One of the other things that I’m doing is trying to make what’s there
more closely follow the implementation approaches of the rest of the
library. It isn’t far off, but that’s one of the things I hope to do
Andrew S. Townley [email protected]