As an end user, I don't really care which rendering engine is used to display my web pages. I just want them working and I want a web browser that is integrated into the desktop and doesn't feel like some kind of external, slapped-on piece of software. Firefox and Mozilla always felt that way, although it has been getting much better in the last two years. Still; integration could be much better.
I don't see the need to support multiple rendering engines in a end-user browser like Epiphany. Epiphany should be easy to use, not a power-tool for web developers. Firefox is the power-tool for web-developers, and that's good. Epiphany I just want to be a really good browser. If that change to WebKit helps the developers to make use of the Gnome password facility or to use other fancy Gnome services, I heartily support it. I find the comparison to crypto algorithms somewhat lacking; implementation of cryptological cyphers are a few kilobytes in size, with well defined input and output ports. There is little room for interpretation and thus little divergence between implementations. A HTML rendering engine however is a different beast completely. So long, Raphael On Thu, Apr 3, 2008 at 3:57 AM, Robert Marcano <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-04-02 at 23:39 +0100, Alp Toker wrote: > > > This is one point most developers are agreeing on. There's little value > > in pluggable web engine backends. The abstraction layers tend to limit > > functionality and increase maintenance overhead with little benefit to > > the user. > > Yes, that is when you are using the engine you like the most, but not > everyone has the same needs. > > I think everyone that used a crypto library saw little value on > abstracting that too, but a few years later something like this happens: > > http://fedoraproject.org/wiki/FedoraCryptoConsolidation > > Fedora is consolidating to only one crypto library (NSS) and read there > is work on patching every application, can we think in the future too > (if thinking on the people that need Gecko now is not enough) > > > > > There are WebKit patches for Yelp, Devhelp (removes 2000+ lines of Gecko > > embedding code, replaced by ~100 lines of WebKit code and drops the > > requirement for a C++ compiler), some experimental WebKit work in > > Evolution and most (all?) other GNOME applications which use web > content. > > 2000+ lines of code that everyone writes on every app, instead of using > a common API, those 100 lines of code what are doing is hiding the GTK > integration code inside the WebKit GTK port. something similar can be > done maintaining the abstraction layer > > > > > As I understand it some of these projects are now just waiting for the > > external dependency to be finalised before switching to WebKit by > default. > > > > Speaking as an upstream WebKit maintainer we're happy to adapt the > > project to meet the needs of GNOME developers, both in terms of features > > and in project organisation, release cycle for the GTK+ port etc. We > > want to see software like Epiphany and GNOME become the driving force > > behind browser development rather than the other way round. > > > > I hope this helps clear up some of your concerns. > > > > Cheers! > ________________________________________ > Robert Marcano > > web: http://www.marcanoonline.com/ > gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD > > > > _______________________________________________ > epiphany-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/epiphany-list >
_______________________________________________ epiphany-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/epiphany-list
