Chris Chabot wrote:
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:- 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 runningJust 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).
http://www.mozilla.org/projects/embedding/MRE.htmlFrom 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/