I'll just add my specific reasoning (plus pro's and con's) for supporting Konq, and some words on how IWebBrowser may be implemented:
- BIG Con: The KDE libraries are GPLed. We can ask the team to perhaps allow us to use it under the LGPL. As far as I am aware, the only reason the libraries are under the GPL is because QT is under the GPL. Since one of the major factors in using KHTML/KJS in WINE will be removing the QT dependency, I see no legal problems to it.. only a matter of if they are willing. If not, the workaround is to implement it as an executable and just use IWebBrowser to send messages/RPCs/whatever to the executable. Using this as a general approach actually has many benefits anyway: : The browser can be upgraded easily, without having to worry about version conflicts against other DLLs. This is a major plus, IMHO : It's far easier to merge upstream changes, as less major modifications would need to be made to the browser core : The rendering engine CAN be replaced easily between Mozilla, Konq, or any other browser code suitably modified to support our IPC mechanism. Even so, we do need to decide on a default to use in WINE cvs. Any IPC mechinism would simply require IWebBrowser calls to be passed from a fairly stubby DLL and COM interface to the browser. The only real modifications needed to a browser would be to understand these calls, and to be able to render to a specified GDI context/hwnd/whichever. --- Other ideas: - Pro: Startup speed is fantastic, and while Gecko is fast while loaded, I really don't think we can use the method Mozilla uses to keep it fast (always run a configured Gecko instance in the background). I don't think WINE should have the overhead or code mess that it would cause. - Con: KHTML and KJS do have a dependency on QT or at least QT-Embedded. Getting a quick and nasty implementation of KHTML (+KJS, which we will need for DHTML/Javascript support, almost all applications that use IWebBrowser use JS) running will be easy, replacing the QT dependencies with Windows GDI/Commctl calls is somewhat more work. - Pro: I know that KHTML is easy to expand in the realm of supporting other URL schemes (res:// etc will be needed in IWebBrowser). I'm not sure how Gecko's architecture works in this respect. - Ender > > - 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 > difficult. > > Konq runs happily so KHTML is probably no problem and I have not heard > of any problems with GtkHTML. >
