Hello everybody! First, some background: As a part of the WebKitGTK+ build process, the Web Extensions API and the DOM bindings are processed by GObject Introspection and are already available to be used from several languages like Python (via PyGObject [1]), or Lua (via LGI [2]). The problem is that those APIs must be used from the web process, and WebKit2GTK+ only supports loading compiled shared objects (e.g. made in C/C++, maybe Vala as well).
It would be desirable to support at least Python web extensions, because it is a very popular language to implement applications using GTK+, and of course it would be desirable to allow using Python for implementing custom behaviour by means of a web extension running inside the web process. (FWIW, we already have a bug [3] for this). Today I have done a quick experiment which demonstrates using a C shim web extension, which uses libpython and helper functions from pygobject.h to load a .py script which can make use of the existing DOM bindings and web extensions API via PyGObject. You can find the proof-of-concept here: https://github.com/aperezdc/webkit2gtk-python-webextension-example While this works, it would still be desirable to have this in WebKitGTK+ itself, in order to avoid projects using Python web extensions copy-pasting and duplicating the code. Also, by maintaning the loader in WebKitGTK+ we can maintain it up-to-date with potential changes in WebKitGTK+ (not very likely to happen, but still), and make sure that newer versions of Python are properly supported. Proposed Implementation ----------------------- (Also written at: https://bugs.webkit.org/show_bug.cgi?id=140745#c2) We don't even need to change the public API to support loading scripts as web extensions. In WebGtkExtensionManager::initialize() we can add code to also search for '*.py' files in the web extensions directory. If any is found, then it would load the Python web extension loader, which in turn would load the '*.py' files as a separate module each, and call their "initialize(extension, user_data)" functions. The Python web extension loader would be a small shared object, at "${prefix}/lib/webkit2gtk-4.0/script-extensions/libloader-python.so" for example, and that would be linked to libpython and all the other dependencies which are not desirable for libwebkit2gtk.so — this way we would not force users to have Python installed. Which loaders are built would be a compile-time option. At runtime, if the script loader shared object cannot be used, extensions written in the corresponding language would not be loaded instead of failing (example: libpython is not installed). This would allow distributions to build WebKitGTK+ with support for the Python script loader, without forcing users to always install libpython. Last but not least, if there are no Python extensions, the Python library and its VM will never be loaded in memory. Note that script loaders for languages other than Python could be added using the same machinery (Lua, JavaScript, etc.). All Python scripts would be loaded in the same Python VM, because it's quite messy to handle multiple VM states with libpython, and PyGObject does not work in that scenario [4]. That shouldn't prevent using multiple VMs for Python in the future, or for other languages which do support multiple VM states well (like Lua). Why not libpeas? (https://git.gnome.org/browse/libpeas/) -------------------------------------------------------- Several reasons: - libpeas extensions implement interfaces, while for the Web Extensions model it fits better to receive the WebKitWebExtension in the script and connect signals to it, and use the APIs normally, like one would do in a C extension. Not using libpeas allows script web extensions to use the same APIs as C extensions, and saves us from writing adapter code or new documentation for script web extensions. - libpeas provides support for writing a configuration UI which allows loading/unloading/enabling/disabling plug-ins. IMHO script web extensions should work in the same way as C web extensions: if a directory for extensions is configured, WebKitGTK loads all of them. - Using libpeas would add one additional dependency. - - - - - All comments/doubts you may have about this are welcome :) -- ⌨ Adrian --- [1] https://wiki.gnome.org/action/show/Projects/PyGObject [2] https://github.com/pavouk/lgi/ [3] https://bugs.webkit.org/show_bug.cgi?id=140745 [4] https://bugzilla.gnome.org/show_bug.cgi?id=677091
signature.asc
Description: signature
_______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
