[webkit-gtk] Deciding the deprecation path for WebKit1

Carlos Garcia Campos cgarcia at igalia.com
Sat Apr 12 01:50:26 PDT 2014

El vie, 11-04-2014 a las 20:43 +0300, Adrian Perez de Castro escribió:
> Hi!
> Carlos Garcia Campos <cgarcia at igalia.com> writes:
> > El mié, 19-03-2014 a las 12:12 -0700, Niranjan Rao escribió:
> >
> >> Gtk annotations is also important for others so that languages like 
> >> python can use it. But this raises a very interesting problem. If python 
> >> like language needs DOM access, how do we do it? There are lot of tools 
> >> out there that depend upon DOM access and use Gtk annotations.
> >
> > That's a good point, we need to figure out a way to support web
> > extensions written in other languages. 
> Most of the applications using languages other than C or C++ are using
> Python or JavaScript. There are GObject-Introspection annotations for
> the API that can be used from Web Extensions, so it should be already
> possible to make extensions in Python/JS.

And vala, I don't know how you can add the entry point symbol in vala,
but since it's compiled to C in the end, maybe we don't need anything
else in webkit side.

> As en example, right now it should be reasonably easy to write a stub
> Web Extension in C that uses the CPython API to create an interpreter
> when the Web Extension is initialized, loads a Python script, and
> calls a function in it passing the WebKitWebExtension and the
> GVariant received by the initialization function [1].
> Another approach would be to teach the WebKitGTK+ injected bundle
> how to load Python/JS/etc web extensions. The problem I see with
> this approach is that WebKitWebProcess could end up linking to e.g.
> libpython, and I would rather avoid linking directly — though maybe
> dlopen()'ing could be an option.

An alternative option could be writing a web extension installed by
webkit that works as a python extension loader, searching for python
extensions to import, and maybe even unloading it if there's no python
extensions available. We make that web extension depend on libpython
instead of the web process.

> One more option could be using the non-UI part of libpeas [2], as
> it already includes loaders for Python2, Python3 and Seed (JS).
> Personally, I would go for having the code for stub Web Extensions
> that load Python/JS available somewhere in a Git repo, and referenced
> From a “Porting to WebKit2GTK+”, so developers can grab the code
> and adapt it to their needs.

I remember we had something like this in ephy-extensions, a script to
write the skeleton of a extension. If it's just a script we don't need a
git repo, we can add it to Tools/Scripts


I'm fine with both options, loading the extensions from webkit directly
makes writing extensions in other languages a lot easier, but providing
a script to write the hard part of the extension wouldn't require any
change in webkit (it's probably more error prone too). 

> -Adrian

Carlos Garcia Campos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20140412/e210e7b1/attachment.sig>

More information about the webkit-gtk mailing list