I am just trying to understand proposals.
By script, do we mean writing a small program that generates extension?
Or proposal is to provide a stub extension that loads users python
script and hands over the control to it?
Does this mean that a python or vala developer needs to have gcc and
other tools required to build extension on his machine? Does a typical
python developer has all those tools? How about debugging code in python
or vala? Those questions are going to come sooner or latter once support
for these language is added.
From python developer's perspective, it might be much easier to say put
this pre built extension at this location, modify this config file to
point to your code which has these interfaces and we will call you back.
From webkit gtk perspective this may not be practical as burden of
maintaining bindings for different languages increases.
We used similar approach for the extension we have, that for all
practical purposes is in Java except for initial stub code borrowed
directly from epiphany code. Main code on start up generates and loads a
simple html. Extension examines the html and loads java classes from the
classpath mentioned in this html and hands over further processing to
this class. This was done before extensions supported any configuration
parameters.
On 04/12/2014 01:50 AM, Carlos Garcia Campos wrote:
El vie, 11-04-2014 a las 20:43 +0300, Adrian Perez de Castro escribió:
Hi!
Carlos Garcia Campos <[email protected]> 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
WDYT?
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
_______________________________________________
webkit-gtk mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-gtk
_______________________________________________
webkit-gtk mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-gtk
