What is Python-Webkit?Python-Webkit is a python extension to Webkit to add full, complete access to Webkit's DOM - Document Object Model. On its own, however, Python-Webkit doesn't actually do anything, because it is only through WebkitDFB, WebkitGTK or WebkitQt4 that Webkit "Document Objects" are actually created (and displayed, on-screen). Thus it is necessary to make a small patch to each of PyWebkitGTK and PyWebkitQt4, to "break out" access to the DOM, but for WebkitDFB, as it is very new, has its own c-based python module, included as part of PythonWebkit. Both PyWebkitDFB and PyWebkitGTK have been done, already.
How do I get Python-Webkit?The Python Webkit DOM Bindings are in development: it's possible to follow or contribute; the source code is available through the git repository. git clone git://git.savannah.gnu.org/pythonwebkit.git For the pywebkitgtk version, please ensure that you check out the "python_codegen" branch: git checkout python_codegen and for the DirectFB (experimental) version, please ensure that you check out the "python_codegen-directfb-2010_11_18" branch: git checkout python_codegen-directfb-2010_11_18 If you fail to check out the correct branch, you will end up with a "vanilla" version of webkit, which will simply not provide you with python bindings.
Building and Build dependenciesThere are presently two options: PyWebkitGTK and PyWebkitDFB. Only one of these is needed.
Building and Build dependencies for PyWebkitGTKIt is best to follow the build instructions on the main webkit web site, with the additional requirements of adding python development headers and the use of PLY (a lexer / parser required to interpret the IDL files). The python header file requirements and PLY build requirements can be fulfilled on debian for example with: apt-get install python-dev python-ply It is worth noting that a very recent version of libsoup is required, so it is best to get the latest git from http://live.gnome.org/LibSoup and then get version 2.29.90 using "git checkout LIBSOUP_2_29_90". Do not attempt to use any other version of libsoup without good reason. It is also adviseable to use ./autogen.sh --without-gnome in order to avoid unnecessary build and runtime gnome dependencies. Also, on debian, a trick can be performed which will get most of the dependencies and build requirements, by utilising the fact that libwebkit is already available as a debian package: apt-get build-essential apt-get build-dep libwebkit-1.0-2 apt-get install libwebkit-1.0-2 apt-get remove libwebkit-1.0-2 It seems strange to install then remove libwebkit, but it pulls in and then leaves all of the dependencies still installed. Do not try this with aptitude or with any other apt package manager: explicitly use apt-get. Other package managers may have a habit of being "helpful", by "cleaning up" after themselves, and removing the very dependencies just installed. Once the build dependencies have been installed, the source code can be compiled: bear in mind that the "python_codegen" branch is needed from the pythonwebkit git repository. It is recommended to create a subdirectory "build", to cd into it, and then use "../autogen.sh". The .gitignore is set up, already, to ignore the "build" subdirectory. You should not need to pass any parameters to "autogen.sh": the defaults should be set up to provide everything needed, already.
Building and Build dependencies for PyWebkitDFBIf using PyWebkitDFB, it is, obviously, not necessary to install PyWebkitGTK, but is is necessary to get the dependencies for WebkitDFB. Perhaps unsurprisingly, this means getting DirectFB. On Debian, this can be accomplished easily with: apt-get install libdirectfb-dev Note: It's also recommended to install libdirectfb-extras, as this includes an X11 plugin which is easier to test with. Edit ~/.directfb and add these two lines: system=x11 force-windowed You will still need python-ply, python-dev, and almost the same build dependencies: again, either follow the instructions on the webkit web site or follow the above "trick" if using debian. Also required is the absolute "basic" window engine, Lite 0.8.10. LiTE 0.8.10 is an absolute requirement not any other version because it includes libleck, a strange and wonderful minimalist widget set on top of LiTE. Unpack, configure, build and install in the usual way by following the standard method for autoconf'd packages: ./configure etc. etc. Note that support for libcurl has been added as a preference over libsoup: you should however still be able to compile with libsoup if that is preferred. Otherwise, install libcurl4 with, for example on Debian: apt-get install libcurl4-gnutls-dev (Support for libcurl was added due to a clash between the LiTE toolkit event loop and the glib/gobject event loop that libsoup relies on. It was simpler to cut out libsoup and use libcurl instead than it was to hack together a reliable non-thread-based way for these two event loops to coexist cleanly) Actually compiling pythonwebkit for DFB requires radically different options from compiling for GTK, so there is a file called CONFIG in the source. You can examine or execute the CONFIG file in the pythonwebkit DFB branch as it contains the present set of options that the developers are using for building. It is best, again, to create a subdirectory "build" and then do "sh ../CONFIG", then follow the standard procedure to make and install. At the end of the install, webkitdfb.so (a c-based python module) will be installed in the python site packages (or dist packages if on debian). This is all that is needed: you should be able to run the dfb demo browser.py found in the pythonwebkit source code or use webkitdfb as a pyjd runtime.
Building a patched version of PyWebkitGTKPLEASE NOTE: as of 11 may 2011, pywebkitgtk is no longer required, as the pythonwebkit gtk build will now build a stand-alone python module which can be imported in python as "import pywebkitgtk". As it is still possible (but unnecessary) to follow the instructions below, they are still available, here. Once pythonwebkit has been installed, it is possible to build a patched version of pywebkitgtk that takes advantage of the new python DOM bindings. Obtain pywebkitgtk from http://code.google.com/p/pywebkitgtk and apply this small patch: pywebkitgtk.patch There is also a version specifically for pywebkitgtk 1.1.8, which is the "stable" version of pywebkitgtk that, importantly, does not have the GObject Webkit Bindings in it (which will interfere with pythonwebkit). pywebkitgtk-1.1.8.patch Once applied, it is then possible to follow the standard build and installation procedures for pywebkitgtk. It is then possible to begin accessing the DOM of the pywebkitgtk WebFrame object, through the addition of the three extra functions provided by the above patch. An alternative to obtaining the "original" version and applying the patch manually is to obtain a pre-patched version from github: https://github.com/lkcl/pywebkitgtk/tree/pythonwebkitgtk_1_1_8 The git clone command is: git clone git://github.com/lkcl/pywebkitgtk.git Once cloned, check out the pythonwebitgtk_1_1_8 branch, with the command "git checkout pythonwebkitgtk_1_1_8". Then, simply proceed with standard build procedures (./autogen.sh, ./configure, make, make install etc. etc. all standard stuff, blah blah).
Building a patched version of PyWebkitQt4Augmenting PyWebkitQt4 to also benefit from the Python Webkit DOM bindings is on the roadmap, but is not as high a priority. However, judging from the tiny size of the pywebkitgtk.patch, it is anticipated to be a relatively small task.
Note about the Source CodeIf you read the code, you will note that the term "open source" appears often. We did not put it there. We are free software activists, working for computer users' freedom. We don't describe our work as "open source" because that term reflects different views which don't include our commitment to freedom. For more explanation, see http://www.gnu.org/philosophy/open-source-misses-the-point.html. This project is meant to extend WebKit. WebKit is a free software package, and we're happy to contribute to it even though its developers endorse open source rather than our views. Most of the code here comes from their version, and that's why the term "opens source" appears in it. We wouldn't have written that, but we didn't change it in their code. We did, however, change the term "Linux" to "GNU/Linux" in many places where it refers to the GNU operating system with Linux kernel, rather than to Linux itself. See http://www.gnu.org/gnu/gnu-linux-faq.html.