m.hearn at signal.qinetiq.com
Mon Nov 11 05:57:13 CST 2002
Well, I for one (though as i'm not writing the code this is just my
comments) would not be willing to choose a rendering engine based on
whether it works or not on platform X.
Both Mozilla and KHTML work quite well on a large number of platforms.
I'd need to know a lot more about why Mozilla doesn't work well on
OpenBSD before ruling out gecko - like, is it due to something missing
on OpenBSD itself. In particular due to the very few numbers of people
using it on the desktop, I'd say if Mozilla doesn't work on that
platform it's the problem of obsd or mozilla, not Wine.
On the other hand, I don't really think Gecko is right for this anyway,
so it's something of a moot point. Generally though I'd say that making
decisions based on what certain platforms can and cannot do is a bad
idea when said platform is in the minority of usage (esp when it's all
open source). Flame away.
On Mon, 2002-11-11 at 11:23, Keith Matthews wrote:
> On 11 Nov 2002 08:29:49 +0000
> "Mike Hearn" <m.hearn at signal.qinetiq.com> wrote:
> > Hi,
> > Please make sure you try whatever rendering engine you choose with a
> > wide sample of CHM pages. From what I remember of my Windows days, CHM
> > help often contains lots of IEisms, from VBScript to IE specific
> > DHTML, ie they're not standard HTML despite the name.
> > Whatever renderer is chosen then should be one we can easily fork and
> > massage into a relatively IE compatible one. Here is a quick roundup
> > of the options based on what I know of the available engines:
> > - Gecko: the best (in terms of features/compatability/speed) rendering
> > engine around. Also benefits from being very widely deployed at least
> > on Linux. Note that soon Mozilla will be splitting into a GRE (gecko
> > runtime environment), then an XRE (xul runtime) layered on top, with
> > Mozilla being an "application" on top of that framework. When this
> > happens, making the GRE a dependancy of Wine would not be such a big
> > deal IMHO, it's only a few megs at the moment.
> > * Pros: We get a high quality rendering engine that we know is
> > powerful enough to do what we need, and when the GRE thing happens
> > it'll be relatively easy to embed too. Already has IWebBrowser
> > interfaces(bitrotted afaik).
> > * Cons: Gecko codebase is huge and complex, adding whatever IEisms
> > are
> > necessary may be hard. Overhead of XPCOM etc.
> I'll add something else here.
> Mozilla is an absolute pain to run on OpenBSD. The porting team have
> recently worked out that they can get it to run as long as they
> statically link it.
> I have no idea if the Gecko part is affected by this, and I'm aware that
> Wine does not currently run on OBSD anyway, but why make things more
> Konq runs happily so KHTML is probably no problem and I have not heard
> of any problems with GtkHTML.
More information about the wine-devel