Re: Nautilus & Web browsing [Was: Re: KDE Interop [Was: D-BUS background]]

[James Henstridge <james daa com au>]

Chris Chabot wrote:

> > > - Mozilla doesn't have native UI (Qt/GTK) and is too complex
> > > - Galeon is too complex
> > > - Phoenix is not native UI
> > > - Epiphany is not finished
> > > - Konqueror is too complex and is tightly bound to having
> > >   KDE desktop running
> > >      
> > Just another option: why not using Nautilus with Gecko so that Nautilus
> > becomes GNOME's web browser just like konqueror is KDE's web browser ?
> >    
>
> Actually thats exactly what i am hoping to see some day.. take just the
> javascript + rendering engine from mozilla, junk 'Necko' and all the other
> libs and link that to gnome-vfs (so its 'native' and consistent w/ the rest
> of gnome) and you would have a hell of a good solutions (Gecko it self is
> very light weight and fast, its the ton of other modules around it that
> bloat it).
Are you sure that it is actually possible to split Gecko from Necko?  
For people who want to embed Gecko, the mozilla people now have a "Gecko 
Runtime Environment", which is essentially the minimum set of mozilla 
components necessary to embed Gecko:
   http://www.mozilla.org/projects/embedding/MRE.html

From the web page it lists necko as part of the GRE, which isn't too 
surprising -- Necko is Mozilla's stream abstraction, similar to how 
gnome-vfs is Gnome's filesystem abstraction layer.  Having yet another 
filesystem/stream abstraction between Gecko and the networking code has 
very little value to current users of Mozilla code.

(not to mention that Mozilla's HTTP code is probably better suited to 
the needs of a web browser than gnome-vfs's http module).

In my opinion, one of the reasons for going with Gecko as a rendering 
engine is that it is one less thing for Gnome to maintain.

If we were going to do something drastic like rip out its networking 
code (which is probably non trivial), then we lose that benefit as we 
would have to maintain the fork.  It seems like a much better idea to 
use the Mozilla subset that moz.org is supporting.

James.

--
Email: james daa com au
WWW:   http://www.daa.com.au/~james/