I'm sorry, but I just think that "rolling our own" browser is an enormous waste
of valuable time especially given that KHTML and WebCore run well and reliably
on modern hardware.
GJC
--- Riccardo <multix@ngi.it> wrote:
> Hey,
>
> it would be nice if you could write gregory a mail about our old
> discussions of writing a new, pure obj-c and pluggable rendering engine
> from scratch. Even if you have little time, maybe if we join forces we
> can make it
> Gregory is thinking again about porting webcore and writing a browser.
> Although I welcome a browser and WebCore/KHTML is now a quite
> "industrial strength" core which is suitable for everyday browsing I
> have some concerns. I don't think webcore is the solution of everything,
> I think it is not very fast in loading up (not in the render speed
> itself. but if you open a new render view it takes some time to load..
> you notice it when opening a new tab/window on slow machines) and it
> uses memory badly (noticeable on a low-mem machine especially: browse
> for one hour, close all windows, leave safari open and you notice you
> machine swaps as wild anyway, with more ram, it just takes longer to
> fill up). Of course I know it has a pretty good JS, CSS and it is a
> quite speedy browser inside Safari. And it is Obj-C++ (I bet gregory
> wants to use it just to test that crutch, I know his geeky soul) But I
> fear that getting webcore would remove the motivation for getting
> another engine, an engine which would be more efficient, more modular
> (possibly) and pure obj-c... ANd I strongly think a browser core should
> be very "quick" so it can be used inside a help viewer, an about panel,
> a generic custom viewer.... wxWidget (with wxHtml) and Java/Swing teach
> us that. These applications usually don't require the features of a
> full-blown browser.
>
> thus the alternatives are
>
> - webcore. I already commented this
> - gecko. SImilar comments to webcore apply. It consumes more ram and is
> even slower to startup, but may render faster and is definitvely often
> more correct in page rendering, since most people which don't use IE use
> firefox.
> - dillo. I know I was a major dillo fan. But thinking that it would give
> us a limited browser (although excellently suited for embedded html
> controls) against quite some work in GTK(fltk in the future?)/GLIB
> porting. ANd we would need to maintain that port
> - omniweb stuff (before they used webcore). A pure obj-c think, the old
> sources are still around. A very nice core, although it would need some
> updating since it supports css1 only essentially and JS is limited. Not
> extremely fast and the license is possibly a problem.
> - cook ourselves browser, something discussed with you, stefan. DO you
> remember the concepts of rendering SGML, HTML, XHTML, XML to a common
> tree? (DOM?) and the having a separate output engine? I remmeber you
> mentioned some parts of the engine already existing. The definition of
> the interfaces would allow plugs so a quick write would be possible,
> with the possibility of future improvments... And make it portable to
> macosx too!
>
> I would recomment the last option as now instead of dillo. It would give
> similar results, but the last approach would be much cleaner and more
> worth the effort. ALso in the long run it could possibly render pages
> quite well as we improve the various plugs.
> I would prefer to start with that before attempting webcore/gecko or we
> get distracted. CBV also reccoments having an eye on omni stuff....
>
> of course one question comes out quickly: can a common interface be
> defined for all those things.. one that encompasses them all without
> being a bad hack?
>
>
> cheers,
> Riccardo
>
>