Re: Backends - was: ANNOUNCEMENT: The Future of Epiphany

Well, Firefox can stay "everything and the kichensink", I don't care. Most third party Firefox plugins don't work on Epiphany anyway, so why bother?

As far as I can remember (back when it forked from Galeon), the project's focus has always been on simplicity and usability. Switchable render backends really don't serve that purpose.

However; the day my mother asks me how to switch HTML render engines in Epiphany (yes, she is using Linux, Ubuntu to be specific, along with the rest of my familiy), I might change my mind and support your request louthmouthed. ;)

I might even open a bug report slash feature request.

So long,

On Thu, Apr 3, 2008 at 10:57 AM, Robert Marcano <robert marcanoonline com> wrote:

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
> <robert marcanoonline com> 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:
>         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:
>         gpg --keyserver hkp:// --recv-key 72A0DCFD
>         _______________________________________________
>         epiphany-list mailing list
>         epiphany-list gnome org
> _______________________________________________
> epiphany-list mailing list
> epiphany-list gnome org
Robert Marcano

gpg --keyserver hkp:// --recv-key 72A0DCFD

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]