I’ve also just sent this to the Galeon and Epiphany mailing lists. Let the chaos begin…
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 Epiphany/GaleonIssues 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 🙂
{ 14 } Comments