Getting back to a working copy of WebKit:

$ svn up
svn: REPORT request failed on '/repository/webkit/!svn/vcc/default'
svn: REPORT of '/repository/webkit/!svn/vcc/default':…
…413 Request Entity Too Large (http://svn.webkit.org)

Combine svn and http transport… And the approximate size of a working copy is around 800MB…

Oh. Now. http://git.debian.org/ has pkg-webkit/upstream.git and pkg-webkit/webkit.git (Debian packaging).

Considering the first one, the history from June 2007 until takes 120MB (du -sh .git). There are two branches: filtered (180MB, .git included), and svn (460MB, .git included).

Also, checking ccache is installed and ready to be used (e.g. by prepending $PATH by /usr/lib/ccache) is always a good idea. Using colormake might also be interesting (once installed, set $MAKE to colormake, done).

So: Can I has a wokking copy?

Sure:

# Fetch
$ git-clone git://git.debian.org/git/pkg-webkit/upstream.git
$ cd upstream

# Check local branches
$ git-branch
* filtered

# Check all branches
$ git-branch -a
* filtered
  origin/HEAD
  origin/filtered
  origin/svn

# Work on the full sources, and make sure
$ git-checkout -b svn origin/svn
$ git-branch
  filtered
* svn

# Set the build environment, and build
$ ./WebKitTools/Scripts/set-webkit-configuration --release
$ ./WebKitTools/Scripts/build-webkit --gtk

# In case the build is interrupted, “make” from there
$ cd WebKitBuild/Release
$ sudo make install

After some efforts related on the epiphany-accessibility page, a quite usable version came out, 0.7.

Debian side

Debian users may want to do the following, which will clone the master branch, which contains the hotkeys extension, on top of the current epiphany-extensions package at the time this project was started (2.18.1-2), build the package (with an unmodified version number, which one might want to change), and install the newly created package (it is assumed one has basic knowledge of how debian package building works).

Initial git-clone, and compilation

git-clone git://git.debian.org/git/users/kibi-guest/epiphany-extensions.git
cd epiphany-extensions
DEB_BUILD_OPTIONS=nostrip debuild -us -uc -b -nc # Some Build-Depends may
                                                 # need to be installed.
sudo debi                  # Installs the generated binary package
pkill epiphany && epiphany # Then Tools>Extensions, and activate Hotkeys

Further updates

git-pull
DEB_BUILD_OPTIONS=nostrip debuild -us -uc -b -nc
sudo debi
pkill epiphany && epiphany

Usage

• restart epiphany
• enable the extension
• read the documentation (Help > Extensions)
• adjust the custom stylesheet
• hit h, enjoy
• report bugs!

Upstream side

So as to ease the merge into upstream, I had a look at using git-svn but unfortunately, it is not meant to be then cloned (so as to have a repository available online for anyone, cloned from the development boxen), at least without cheating.

That's why the following has been chosen: master keeps on having the initial tree and the initial commits. upstream is an equivalent of an SVN working copy. upstream-hotkeys contains the upstream branch augmented with the hotkeys extension.

At the time of this writing, bugfixes and new feature additions will probably happen in master and then get pulled in the upstream-hotkeys branch.

Next step: get epiphany 2.19 built and test the upstream-hotkeys branch by building against it.

A patch against current upstream SVN (r1569) is available, it is sufficient to do the following to enable the hotkeys:

wget http://blog.mraw.org/projects/epiphany-accessibility/upstream-hotkeys-icons.diff
svn co svn://svn.gnome.org/svn/epiphany-extensions/trunk hotkeys-test
cd hotkeys-test
patch -p1 < ../upstream-hotkeys-icons.diff
./autogen.sh --with-extensions=default,hotkeys
make
sudo make install

When reading the Writing Epiphany Extensions documentation, I followed the link to devhelp, which is a documentation browser, primarily designed for browsing GNOME API, but not limited to that.

After having installed libgtk2.0-doc and libglib2.0-doc, it looks like I'm ready to have a look at actually writing an extension.