The future of Galeon

[Philip Langdale <philipl mail utexas edu>]

Hi all,

Tommi, Crispin and I were all able to attend the GNOME summit last
weekend, even though Crispin had to pay his own way :-) So, it was
a good opportunity for us to sit down and discuss the future of Galeon.
All of us are very much working fulltime which limits the extent to
which we can hack on Galeon and the amount of activity you've observed
speaks for itself.

As such, we've reached the conclusion that we have to change our
approach if we're going to avoid Galeon getting stale or bit-rotting;
which is important for all of us, as we all use Galeon because we
still think it's the best thing out there :-)

So, what does changing our approach mean? It means considering Epiphany
in a new light; Galeon still does a lot of things, small and large, that
Epiphany either doesn't do or doesn't do as well, but at the same time,
there are some areas where they've moved in front, and most importantly
Epiphany has a bunch of active maintainers who are handling the things
that we struggle to do for Galeon. But you say: Epiphany doesn't fit
my needs or I'd be using it already! True, so our proposal is to bring
Galeon to Epiphany.

Epiphany has a powerful extensions mechanism that exposes many of the
core structures of the program and there is a general willingness to
expose more as necessary. This means that many galeon features can be
recast as extensions, and Crispin has already done this for a couple
of things: the sidebar is now in epiphany-extensions and he's got a
few more hidden away such as in-browser view-source. Also don't forget
that some other features have been independently ported as extensions
already, such as the javascript console.
There are a few galeon features which are hard to implement as
extensions and/or are of a class that makes them desirable within the
base Epiphany package, and these should be directly ported. I've already
made a couple of checkins to port back/forward history copying and
middle-clicking on history entries.

Between these two approaches and the more pragmatic direction that
epiphany is moving in these days (heirarchical bookmark support has
just been checked in!), I believe that we can reach a point where
Epiphany + a set of extensions will provide the same functionality that
Galeon does today.

This seems an optimal solution for everyone; it allows us, the galeon
developers, to avoid duplicating work with epiphany team, it will allow
users to leverage the best from both browsers and most importantly, it
puts galeon on a much firmer footing for the future that is not so much
at the mercy of our ability to find time to hack on it.

I hope that this sounds like a good long term strategy to everyone, but
if you do find yourself recoiling from it, do realise that the current
approach is unsustainable and will almost certainly result in galeon
becoming unmaintained or falling too far behind in some areas, meaning
that you'll be struggling to keep using it anyway.

This process will probably take some time given our other commitments,
so we intend to make a formal 2.0 galeon release (long overdue really)
and keep that compiling against newer releases of mozilla, but our
efforts will be directed towards this extension project.

Of course, anybody who wants to help out, either with the extensions
or with maintaining the current galeon codebase, is more than welcome!

I've added a wiki page at: http://live.gnome.org/Epiphany_2fGaleonIssues
which lists current stuff I can think of. I encourage anyone to add
anything that I've missed, but if you want to list a Galeon 1.2 feature
please categorise it separately :-)

--phil