m.hearn at signal.qinetiq.com
Mon Nov 11 02:29:49 CST 2002
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
* Cons: Gecko codebase is huge and complex, adding whatever IEisms are
necessary may be hard. Overhead of XPCOM etc.
* Notes: why would Wine require the Windows version of Gecko?? Why not
simply embed Gecko into the X window constructed by Wine? I'm pretty
sure this can be done. I know a lot of people wouldn't want a win32 and
a linux version of gecko installed at once, even if one was in their
fake windows drive. If it's a case of Wine windows can't easily embed
others via XEMBED then maybe this functionality could be worked on
- KHTML: designed for embedding since the start, KHTML is used in the
KDE Help system, so we know it's got good enough performance for that,
but it also does quite a good job as a web browser (though not as
compatible with the web as gecko). Written in pure C++ so no object
model overhead. Codebase is (fairly) simple for a rendering engine from
what I hear, so could be easily adapted to add any IE specific html.
Cons: not as widely deployed as Gecko, though I don't think it's far
behind. Would start easily depending on other parts of KDE however, like
- GtkHTML: I'd guess a lot of machines have GTK on in one form or
another, hence a high likelyhood of this being present. Having wine
depend on GTK is not such a big deal either. GtkHTML is probably the
weakest renderer of the bunch, for instance I don't think it has script
support, but is pretty fast and easily embedded.
Although Gecko is a nicer renderer, I think it's wise to go with KHTML
here. If necessary the code can be statically linked into a Wine DLL. I
don't know what the policy is on including C++ code in Wine, but I can't
see why this would be a problem. KHTML has relatively good support for
web standards, and should be easily extendable (though you'd need to do
a proper evaluation) to support the IE level zero dom.
Esp startup time is to be considered, gecko requires initialization of
XPCOM and other stuff, also the biggest problem with gecko is that the
embedding interfaces tend to change with every major release of Mozilla.
As Moz is often kept quite up to date, that means Wine would constantly
break a la Galeon <yuck>. KHTML is far more stable, and could be bundled
with Wine anyway.
On Sun, 2002-11-10 at 09:40, J.Brown (Ender/Amigo) wrote:
> Just so people don't double up, I'll let everyone know I'm working on a CHM viewer.
> Although I still havn't worked out how I will do the actual HTML viewing,
> my first priority is to actually build code to parse the file :)
> I might even ponder implementing a simple IWebBrowser implementation based
> off of Konq-Embedded/khtml, which would be -extremely- easy... and best of
> all, light-weight (there is NO way I'm going to install Mozilla/Win32 to
> have large portions of WINE working, I can't afford the diskspace!)
> Of course the whole GPL vs LGPL thing is a bit of an annoyance.
> - Ender
More information about the wine-devel