ANNOUNCEMENT: The Future of Epiphany
- From: Christian Persch <chpe gnome org>
- To: Epiphany Mailing List <epiphany-list gnome org>, Gnome Release Team <release-team gnome org>, Gnome Development Announcements List <devel-announce-list gnome org>
- Subject: ANNOUNCEMENT: The Future of Epiphany
- Date: Tue, 01 Apr 2008 15:21:16 +0200
Over the last few months, the Epiphany development team has been
discussing the future of the Gnome web browser. We feel that we haven't
been living up to the full potential of a well-integrated Gnome
application, due to both internal and external constraints.
The Epiphany user interface is built on top of an abstraction layer
above the web rendering engine, enabling us to support multiple
back-ends. Currently Epiphany supports the Mozilla browser engine
(Gecko), and the WebKit engine.
The Epiphany dependency on Gecko creates a number of problems for us.
The Gecko release cycle is very long (e.g. Gecko 1.8 was released with
Firefox 1.5 in 2005; 1.8.1 with Firefox 2.0 in 2006 and 1.9 will be
released sometime this year with Firefox 3.0), prone to delays and not
synchronised with the unvarying 6-month Gnome release cycle.
Furthermore, it and the feature work on Gecko are mostly driven by the
Firefox browser, our main competitor on the Gnome desktop. Also the
embedding API of Gecko (GtkMozEmbed) has been unmaintained and stagnant
for a long time. Finally, the current plans for "Mozilla 2.0" bring much
uncertainty to us, as well as much work to account for their proposed
big API changes.
We are a small team, with only one maintainer and a hand-full of
regular contributors. Maintaining the abstraction layer, and the Gecko
back-end require lot of effort and time. Much time alone is spent on
keeping up with Gecko API changes, and we have not had much
contributions to the Gecko back-end in a long time.
Therefore we have decided to radically change the future of Epiphany
in the upcoming 2.24 development cycle. We will drop the abstraction
layer, making the code more maintainable, allowing faster development
and enabling us to take advantage of the features of the back-end
Furthermore, we will choose only one web engine back-end to support
and concentrate our efforts on it instead of spreading our efforts to
multiple back-ends and restricting us to the common features all
This single back-end will be * WebKit *.
We see several advantages in WebKit. These include:
* The WebKit APIs. The API has been designed from the ground up, and
feels like any other GObject based API. A two-way GObject bindings to
this will allow us and our Extensions to access the DOM directly, which
hasn't been possible before in Epiphany in either C or Python.
* WebKit uses Gnome technologies directly. Similarly to Gecko, it uses
Cairo for graphics, and Pango for the rendering. On top of that, it uses
libsoup for the network layer, and GStreamer for the <video> and <audio>
tag support in HTML5.
* Starting in time for Gnome 2.24, WebKit/GTK+ will implement a
6-month release cycle synchronised with the Gnome release schedule.
* We feel that WebKit has the momentum, and can bring more developers
to both Epiphany directly and the Gnome platform by extension.
WebKit/GTK+ already has more people working on it than are working on
either GtkMozEmbed or the Epiphany gecko back-end.
* WebKit is a better match for *other* uses in Gnome, e.g. as a HTML
widget in Yelp, in Devhelp, and as an editor in Evolution replacing
We will propose WebKit as an approved external dependency for Gnome.
In case that we are unable to complete this development in time for
2.24.0, we will delay the new Epiphany to 2.26. For this end, we will
maintain the gnome-2-22 branch in a state that allows us to potentially
make the 2.24.0 release off of that branch.
The Epiphany developers
Diego Escalante Urrelo
Reinout van Schouwen
[Date Prev][Date Next
] [Thread Prev][Thread Next