Author: Stephen Feller
While the idea of bringing some of Galeon’s more advanced features to a lightweight browser was kicked around even before the late-2002 fork, plans were not sorted through and solidified until the GNOME summit in Boston a few weeks ago, where developers ironed out how extensions and code changes would be worked on.
According to the announcement from Galeon developer Philip Langdale, development plans for new and expanded functions are to be offered to users by way of extensions, with core changes limited mostly to things the average user likely will not notice. A wiki has been set up listing “all the stuff Epiphany doesn’t do,” Langdale said. The list includes toolbar and bookmark improvements for the browser’s core, improved control and preferences for the extension interface, and a mix of actual extensions split between some that can be added now and many more that are hoped for the future.
“Most of the list is seemingly minor stuff, but it does make a difference,” Langdale said. “It’s our general hope that we eventually get to everything on the list.”
Among the improvements Langdale said he’d like to see done first are the Personal Data Manager and easy menu shortcuts for making changes to cookie, popup, and other behavior, as well as improving various quit options, including a function to exit Epiphany and retain memory of the current set of open pages. Langdale said he has already ported back/forward history copying when opening as link in a new tab and middle-click support for the back/forward/up actions for the software’s core — features that don’t get in the way of or confuse users who don’t care about them.
Epiphany developer Christian Persch said the plan to have developers work together specifically to improve the one browser is a “great validation” of the effort put into the extensions interfaces in Epiphany. Noting that some Galeon-like features such as the JavaScript console, sidebar, and stylesheet selector are already part of Epiphany, Persch said that developers on the two projects will now be working toward a more common goal and duplicating less work.
“I think it’s a smart move for both sets of developers,” Persch said. “By concentrating that effort on one codebase, we can simultaneously improve the overall quality and features, while still leaving more time to work on the front-end side of the browser.”
History
The Galeon project was started in mid-2000 by Marco Pesenti Gritti after he made an unsuccessful search for a Web browser that worked well with GNOME, and was both stable enough and simple enough for average users to handle. Gritti, who declined to comment for this story, based the browser on Mozilla 1.0 and used its Gecko layout engine, which at that time had not yet been released.
Conversations over whether Galeon had gone beyond Gritti’s original vision of a simple browser began with the release of version 1.2, which was feature- and preference-heavy. The rewritten Galeon 1.3 carried far less with it, and as a result has been referred to as a stripped version of the browser, according to the history included at the Galeon Web site.
Gritti’s changes, justified by his original intent for the browser and position as lead developer, sparked a debate on the galeon-devel list as to what the best path was for Galeon, most notably in October and November 2002. The debate is typified by the responses to Gritti’s posting of a specific list of plans
he had for release 1.3 — at that time expected to be 2.0 — which was not in line with many other developers on the project, including Langdale.
Intending to make the user experience simpler, and to follow the GNOME Human Interface Guidelines (HIG), Gritti left the Galeon project in November 2002 to start Epiphany, which has since become the default GNOME browser.
“It all came down to disagreements over the whole GNOME fad for extreme simplification in those days,” Langdale said.
Moving forward
The motivation for the rapprochement on the part of the three main Galeon developers — Langdale, Crispin Flowerday, and Tommi Komulainen — was to prevent the Galeon code from “getting stale or bit-rotted,” Langdale said, because all three have full-time commitments and cannot devote much time to working on the browser.
As the Galeon team works with Epiphany, they will also continue maintenance work on the Galeon code, keeping up with API changes to Mozilla. Although he expects Galeon 2.0 to be finished and released before the end of this year, Langdale said working with Epiphany will allow Galeon to continue on in some form while also contributing to more a widely used, and similar, software with a “more active” developer base that maintains it.
“There’s been a lot of communication and sharing with the current Epiphany development team for some time … so this builds upon that base,” Langdale said. “It was a decision that we, the Galeon developers, made independently of the Epiphany team. We did talk about it with [them] before the announcement and they are happy that our efforts are now more convergent than before.”
While it would seem as though the ideological differences between Galeon and Epiphany developers have been solved, GNOME developer Murry Cumming pointed out that the two projects have never had fundamentally different goals. He said the most notable similarity is their openness to well-explained contributions at high design levels and the fact that “they are very energetic about improving the user experience.”
Cumming said both Epiphany and Galeon have contributed a great deal to GNOME over the years, and that it’s good for both those browsers and the Mozilla/Firefox code they are built on, that the two groups of developers will now be working together. He added that what was most important about the projects coming back together is the agreement that Gritti’s original goal of simplicity matters as much as it has come to in the last year or so.
“What’s far more interesting … is how Firefox is becoming the easy-to-use browser that the Epiphany project was formed to create,” Cumming said. “Epiphany still has a lead over Firefox in terms of desktop integration and ease-of-use; however, what’s different now is that there’s a consensus that ease of use is that important.”
