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.