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.
>