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. * 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 first.
- 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 KJS for JavaScript (does wine needs its own javascript interpreter anyway?)
- 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.
thanks -mike
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