On Thu, 2008-04-03 at 08:23 +0200, Raphael Bosshard wrote: > 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.
typical response of someone that only cares about their needs, In our case as enterprise users we need Gecko for thirdparty software support issues, but I think It is impossible to make people think in other people needs (even when you offer help) > > 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 ________________________________________ 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
